Mission Planner 1.3.74 build 1.3.7563.
Copter: https://github.com/ArduPilot/ardupilot/commit/08b8a43ab583301b0f1de358d8a0273caf97e24b
PXFmini (MPU9250 onboard).
This board has flown with Copter 3.4.
I get InternalError 0x1000000
and DISARMED FAILSAFE.
I will do more testing and get logs soon. It sort of goes away for a second or two but error usually there 99% of time,.
Messages screen does not show imu_reset error on mine.
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.
We’ve been experiencing the same issue for several months now and we don’t know why, since they appeared out of nowhere using exactly the same hardware and different software versions, even old ones that never had any issues before. It happens completely randomly on different PixHawks with different firmware versions and it’s been impossible to replicate on a test bench.
Yesterday for example the error reappeared after 4 or 5 months without seeing it (.tlog here).
After restarting the drone, the error has disappeared, but on the next flight it behaved badly and it was very complicated to land it. It worked fine for the first few minutes and then suddenly went crazy.
Also, no matter how much the throttle would go down, the aircraft would still go up, unless the throttle was at minimum, which cut the engines off completely.
That was the only way to bring it down “in a controlled” manner, letting it fall little by little with the motors off.
Does this have anything to do with the Internal Error? Any idea how to debug it?
The aircraft is a QuadPlane controlled by a Cube Orange with ArduPlane 4.1.6 (eddf0367). Attached log here.
Any help or suggestion is welcome. Thanks.
This has been resolved since 4.3.3. Update to the latest stable release.
For reference:
As for the control issues, I’m not sure. Maybe @xfacta has some insight.
I realize this is the copter thread, but Google pointed me here. I had 3 flights on Plane yesterday (4.4.dev), and only on the 3rd flight I had thousands of these IMU0 messages - something like 10 Hz I think. The plane flew absolutely fine in manual, stabilize and auto modes.
Edit: looks like the messages were logged at 50 Hz.
