Internal Error 0x100000 after update from 4.1.1 to 4.1.2


after update from copter 4.1.1 to 4.1.2 I get the internal error 0x100000 after some minutes of flight.
The copter continues to fly without any visible problems.
This is repeatable on every flight.
Back to 4.1.1 and the internal error does not appear any more.

Matek H743-Slim, BDShot, FPort with Yaapu telemetry and TFmini LIDAR.

Here is the log

2021-12-17 16_09_16

I don’t see it in the log. We need to see the rest of the error string.

“InternalError 0x100000” is all what is displayed in Mission Planner.

That error is “flow_of_control” and there will be a line number associated with it, can’t tell you anything without it. In the messages tab of mission planner there should be the text as well.

I hope this will help you. Seems like this problem is with hardware.

PreArm: Internal errors 0x1000000 l:168 imu_reset - ArduCopter / Copter 4.1 - ArduPilot Discourse

What does “gyros not healthy” mean - ArduCopter / Copter 4.0 - ArduPilot Discourse

Different error - one is 0x1000000 and the other is 0x100000

It is almost dark outside, bu made another flight …
Also nothing in the messages-tab:

Mission Planner is version: build 1.3.7906.6208

I made two more flights at a location where I can watch the copter a bit better.
Again an endless WP loop with Terrain heigth 3m above ground with TFmini Lidar.
Primary is IMU1 (MPU6000), because I do not trust the ICM20602.
Both IMUs are set to fast sampling

When the internal error happens, the copter falls down about 1m but then continues to fly normally. See the end of the logs shortly before I terminate AUTO mode:

After disarming this message is shown in Mission Planner:

I’m not 100% sure, but I think in both cases the error happend almoast at the same position, after the last WP on the way to the 1st WP … somewhere here:

Ok, that’s this one:

libraries/AC_AttitudeControl/AC_PosControl.cpp:967: INTERNAL_ERROR(AP_InternalError::error_t::flow_of_control);

Yeah, I have seen this before. @Leonardthall / @rmackay9 this is in update_z_controller(). I really don’t think this should be an internal error - it happens too frequently.

I think we need to fix this problem, not remove the check. This looks like a wrapping problem. The PM.MaxT shows it going to 68036, suspiciously close to 2^16 = 65536. When normally it is 2580. 2^16+2580 = 68116. Pretty close…

Looking at the code I can’t see why given it the variables are uint64_t (well over 8 thousand years isn’t it?).

Is it being cast to something in the process… This tends to be out of my skill set.

// is_active_z - returns true if the z position controller has been run in the previous 5 loop times
bool AC_PosControl::is_active_z() const
    return ((AP_HAL::micros64() - _last_update_z_us) <= _dt * 5000000.0);

But I think this is a real bug, but not a bug that can cause a problem, at least here. Other than the position control reset.

The main reason for this check is to pick up when the library is used un-initialised. And that is a real problem that can cause a crash.

The 68ms delay on MatekH743 (and a few other boards) is fixed in copter 4.1.3

1 Like

Update to 4.1.3-rc1 fixed the problem!

In the past 1.5 hours my copter was flying this infinite WP-loop (Video) without problems.
I also think, that the Z-axis oszillation in Loiter mode (with TFmini Lidar) is also better than before.

For me the best result ever!
Thank you so much!



nice video. It is looking good, especially the corners…

“The 68ms delay on MatekH743 (and a few other boards) is fixed in copter 4.1.3”

@tridge , what is this “68ms delay” issue that you referred to above? I am wondering whether it would be safe for me to upgrade to 4.1.3 from the version I currently use (4.0.7). I know for a fact that 4.1.0 did not work with my Matek H743-slim, so I am curious what this fix was. Thanks.

Same board H743-Slim, fly the master of today, same error exactly when I switched to position hold, also detected it during an Autotune.

ESC, 231820961, 0, 8495, 8542, 18.13, 5.81, 50, 274, 0, 0
ESC, 231820967, 1, 7657, 7657, 18.06, 5.78, 50, 337, 0, 0
ESC, 231820999, 2, 8514, 8542, 18.06, 5.52, 50, 320, 0, 0
ESC, 231821005, 3, 7600, 7600, 18.08, 5.45, 50, 312, 0, 0
ERR, 231821016, 30, 1
MSG, 231821028, Internal Errors 100000
RFRF, 10, 0
RFRH, 231821367, 6026
RISI, -0.01287492, 0.0004963517, -0.01989855, -0.0001963262, 0.0001628904, -1.343864E-05, 0.00150832, 0.00150832, 15, 0
RISI, -0.002518023, -0.004039068, -0.008407761, -0.0001350282, 8.357844E-05, 2.012618E-05, 0.000998745, 0.0009987513, 15, 1
RFRF, 10, 0

I went through the pos_hold and the position controller but can’t see any way it can skip updates to the position controller. I think this is a case where the loop time is very low for some reason and we miss 5 consecutive updates due to a long loop.