Internal errors 0x100000 l:917 flow_of_ctr

I’m flying a quad copter with a BeagleBone Blue as a flight controller and Arducopter 4.2.1. After a few minutes of flying Arducopter reports error 0x100000 (flow_of_control) and doesn’t want to arm again after disarming: PreArm: Internal errors 0x100000 l:917 flow_of_ctr. It’s seams like the error is caused by “z_control” not being initialized before updating in libraries/AC_AttitudeControl/AC_PosControl.cpp:917 (tag Copter-4.2.1)
Heli frame, prearm Internal error 0X100000, L:602 flow_of_ctr seams to be related, but not the same.

What can I do to confirm that this is a bug that should be reported?

I found Internal Error 0x100000 after update from 4.1.1 to 4.1.2 which seams to interpret the error as a time warp or other scheduling glitch, but apparently it got (kind of) fixed already.

I can also find the PM.MaxT value being quite high at the same time as the error message.

Has the problem of 0X100000 been solved?
I also encountered this error.

I’ve encounter a similar error, no fix yet. I’m on copter 4.3.0

Your post was a long time ago but maybe it could be related.

I also had this issue particularly after updated firmware to AC 4.3.0 on CUAV v5 Nano.
Any one has solution or what it could be the problem?
@rmackay9 at it will cause to flight controller?

@Leonardthall and I need to investigate this further but we suspect the issue is that we have quite tight checks on the main loop rate and some autopilots are hitting delays that are longer than this tight constraint.

1 Like

I’ve had this issue on 4.3, as you probably already know since I tagged you.

How do I know if there isba fix out? Should I just read the notes on 4.3.x upcomming beta firmwares?

Thanks!

Saw this issue as well when I have the rate at 800 on my H743. Dropping to 400 resolves it, though is kinda odd.

hmm, yeah.

I could try that and see if it resolves my issue as well. Wonder if there is any down side to dropping it.

I’m also going to try the copter 4.4.0 beta firmware and see if it’s the same there

Today I experienced the same error on 4.2.3. I am using mRoControlZeroOEMH7 as my autopilot.

It happened several times. Once it coincided with SubSys:30 ECode:1 – I haven’t tracked this one down yet in the firmware code. Will check on it tomorrow.

If anyone has ideas on how to resolve it other than dropping the rate, please share (the mro runs at 400hz)

I think @rmackay9 and the developers are looking into this at the moment!

Thanks guys. I will stay tuned. If additional info/logs etc is necessary I can help

I tracked the “SubSys:30 ECode:1”

According to AP_Logger.h subsystem 30 is internal error and 1 means failed to initialize … so not super helpful

enum class LogErrorSubsystem : uint8_t {
MAIN = 1,
RADIO = 2,
COMPASS = 3,
OPTFLOW = 4, // not used
FAILSAFE_RADIO = 5,
FAILSAFE_BATT = 6,
FAILSAFE_GPS = 7, // not used
FAILSAFE_GCS = 8,
FAILSAFE_FENCE = 9,
FLIGHT_MODE = 10,
GPS = 11,
CRASH_CHECK = 12,
FLIP = 13,
AUTOTUNE = 14, // not used
PARACHUTES = 15,
EKFCHECK = 16,
FAILSAFE_EKFINAV = 17,
BARO = 18,
CPU = 19,
FAILSAFE_ADSB = 20,
TERRAIN = 21,
NAVIGATION = 22,
FAILSAFE_TERRAIN = 23,
EKF_PRIMARY = 24,
THRUST_LOSS_CHECK = 25,
FAILSAFE_SENSORS = 26,
FAILSAFE_LEAK = 27,
PILOT_INPUT = 28,
FAILSAFE_VIBE = 29,
INTERNAL_ERROR = 30,
};

// bizarrely this enumeration has lots of duplicate values, offering
// very little in the way of typesafety
enum class LogErrorCode : uint8_t {
// general error codes
ERROR_RESOLVED = 0,
FAILED_TO_INITIALISE = 1,
UNHEALTHY = 4,
// subsystem specific error codes – radio
RADIO_LATE_FRAME = 2,
// subsystem specific error codes – failsafe_thr, batt, gps
FAILSAFE_RESOLVED = 0,
FAILSAFE_OCCURRED = 1,
// subsystem specific error codes – main
MAIN_INS_DELAY = 1,
// subsystem specific error codes – crash checker
CRASH_CHECK_CRASH = 1,
CRASH_CHECK_LOSS_OF_CONTROL = 2,
// subsystem specific error codes – flip
FLIP_ABANDONED = 2,
// subsystem specific error codes – terrain
MISSING_TERRAIN_DATA = 2,
// subsystem specific error codes – navigation
FAILED_TO_SET_DESTINATION = 2,
RESTARTED_RTL = 3,
FAILED_CIRCLE_INIT = 4,
DEST_OUTSIDE_FENCE = 5,
RTL_MISSING_RNGFND = 6,
// subsystem specific error codes – internal_error
INTERNAL_ERRORS_DETECTED = 1,

// parachute failed to deploy because of low altitude or landed
PARACHUTE_TOO_LOW = 2,
PARACHUTE_LANDED = 3,
// EKF check definitions
EKFCHECK_BAD_VARIANCE = 2,
EKFCHECK_VARIANCE_CLEARED = 0,
// Baro specific error codes
BARO_GLITCH = 2,
BAD_DEPTH = 3, // sub-only
// GPS specific error coces
GPS_GLITCH = 2,
};

Out of curiosity what does the PM>NLon graph show in the log?

Yes but it is 0 the entire time. Also the rest of the PM values don’t seem to change much compared to before or after the error is announced

Sorry if I missed it but was there a log attached somewhere?

Dear Leanard, sorry for the late reply, I was away for a while.
I worked on this yesterday. I use a modified version of Copter 4.2.3 and some of my code that was running essentially AltHold’s run() was an issue. I was running the althold run from a few versions before and the order in which the functions were called was different.

I updated with the current AltHold code and the error no longer appears. So in my case I was the source of the problem.

Thanks for letting us know.

I’ve placed links to some alpha testing binaries in this thread that may help resolve these issues.

No pressure of course but if people are happy to help us test these binaries that would be a great help!