This error message occurs because our IMU driver has noticed a problem with the IMU and has had to reset it. In some cases at least we think this is a hardware problem and all that has changed is that we are alerting the user to the problem.
In any case I’ve added this to the Copter-4.1.0 issues list so hopefully some other devs can look into it once you download a log.
@rmackay9 My messages tab doesn’t mention the imu_reset. Is your statement still accurate?
Thanks for all your help with mine and others.
Yes, I think 0x1000000 is the imu_reset (table of error codes is here in the code). We don’t currently print a human readable string for the internal errors perhaps because we aren’t expecting them to be very common at least in stable releases… we may be wrong though so it’s worth us thinking about improving the message.
We found the same Internal Error 0x100000 after a SmartRTL (successfully completed except for LAND_SPEED). Just after landing, we disarmed and changed flight mode, at this time MP reported the Internal Error 0x100000, no other relevant messages.
Copter 4.0.7.
I am not sure if I should post here. I see I didn’t get the full error message in the photo but maybe this will help.
These errors didn’t show up with the previous firmware. I am using an original Pixhawk from 2014, not a clone.
I am also attaching all the logs of the same day. I flew this morning at ±7am. Not sure which log had the error in. Probably 175. I was changing flight modes in mission planner and saving the flight modes to the drone.
This is all the logs
This is the photo of my screen
@Taskman @xfacta I am facing the same error ‘PreArm: Internal errors 0x1000000 l:168 imu_reset’, 24 seconds after Power ON of the Pixhawk(I am using the Cube Orange), it would be of great help if you would help me out with that.
If you need any additional information for resolving the issue do let me know.
I am getting the same error but randomly in flight, also with cube orange
Hi
Sorry, it was so long ago and so many things went wrong. Everything was just so random for me since I didn’t and still don’t know anything.
I upgraded and downgraded firmware a few times. I disconnected things and reconnected things. Not much more you can do I think.
Kobus
I suspect that Internal Error was changed to remove/fix it or maybe update the text so it was more meaningful. The consensus was it was due to a hardware error.
Make sure you are on latest stable firmware version, there have been many important fixes.
Also check you are using EKF3 after the upgrade.
Similar issues are reported infrequently here:
@Taskman During the whole process I assume you didn’t changed the Flight controller. Keeping the flight controller same, you switched around with the firmware versions, and all the hardware on the aircraft were kept same.
I also seem to remember that earlier firmware versions didn’t show this error - meaning the hardware could still be faulty but you are not warned.
I didn’t change the flight controller. Mine is from before 2020. I want to say from around 2014 but I don’t have the invoice with me now.
Since I crashed and destroyed the drone about 3 times a week I changed everything except the controller
I had the same problem with FMU V3 Arduplane 4.2.1 firmware.
Is there any other way to solve it now?
void AP_InertialSensor_Invensense::_fifo_reset(bool log_error)
{
uint32_t now = AP_HAL::millis();
if (log_error &&
!hal.scheduler->in_expected_delay() &&
now - last_reset_ms < 10000) {
reset_count++;
if (reset_count == 10) {
// 10 resets, each happening within 10s, triggers an internal error
// IMU reset
INTERNAL_ERROR(AP_InternalError::error_t::imu_reset);
reset_count = 0;
}
} else if (log_error &&
!hal.scheduler->in_expected_delay() &&
now - last_reset_ms > 10000) {
//if last reset was more than 10s ago consider this the first reset
reset_count = 1;
}
last_reset_ms = now;
uint8_t user_ctrl = _last_stat_user_ctrl;
user_ctrl &= ~(BIT_USER_CTRL_FIFO_RESET | BIT_USER_CTRL_FIFO_EN);
_dev->set_speed(AP_HAL::Device::SPEED_LOW);
_register_write(MPUREG_FIFO_EN, 0);
_register_write(MPUREG_USER_CTRL, user_ctrl);
_register_write(MPUREG_USER_CTRL, user_ctrl | BIT_USER_CTRL_FIFO_RESET);
_register_write(MPUREG_USER_CTRL, user_ctrl | BIT_USER_CTRL_FIFO_EN);
_register_write(MPUREG_FIFO_EN, BIT_XG_FIFO_EN | BIT_YG_FIFO_EN |
BIT_ZG_FIFO_EN | BIT_ACCEL_FIFO_EN | BIT_TEMP_FIFO_EN, true);
hal.scheduler->delay_microseconds(1);
_dev->set_speed(AP_HAL::Device::SPEED_HIGH);
_last_stat_user_ctrl = user_ctrl | BIT_USER_CTRL_FIFO_EN;
notify_accel_fifo_reset(_accel_instance);
notify_gyro_fifo_reset(_gyro_instance);
}
///////////////////////////////////////////////////////////////////////////////////////
if (!_check_raw_temp(t2)) {
if (!hal.scheduler->in_expected_delay()) {
debug("temp reset IMU[%u] %d %d", _accel_instance, _raw_temp, t2);
}
_fifo_reset(true);
return false;
}
//////////////////////////////////////////////////////////////////////////////////////////
/*
fetch temperature in order to detect FIFO sync errors
*/
bool AP_InertialSensor_Invensense::_check_raw_temp(int16_t t2)
{
if (abs(t2 - _raw_temp) < 400) {
// cached copy OK
return true;
}
uint8_t trx[2];
if (_block_read(MPUREG_TEMP_OUT_H, trx, 2)) {
_raw_temp = int16_val(trx, 0);
}
return (abs(t2 - _raw_temp) < 800);
}
It indicates FIFO corruption. The temp check is to try and detect this. Causes can be CPU overload
thanks for your guidance.
It is indeed related to the temperature of the IMU, which may be caused by the poor soldering of the IMU.