Control block reentered error

[eufrizz]

Hi! Just curious about the "Control block reentered" error that seems to appear quite often for me when running an ESC. My understanding is that it occurs when the ADC interrupt (which is the basis for the 20kHz control loop timing) triggers while a control step is still processing.

1. Does this happen often for you too?
2. What causes it? On firmware v0.8.17, the CPU busy cycles seemed to be about a third of the total cycles, so there should be plenty of headroom (this endpoint seems to have been removed in later firmware). How consistent is the timing on the ADC interrupt, does it just jitter and cause this clash by chance? Or is there a more fundamental issue?
3. How important is it? The motor seems to run fine when the error is ignored/commented out, I guess because at 20kHz one missed step//repeat measurement is inconsequential.

[yconst]

1. In Debug mode only.
2. So up until 1.6.x there were some calls to peripherals that take a long time to complete, this in addition to processing CAN frames and the fact that in Debug no functions are placed in RAM (otherwise breakpoints do not seem to work), meant that some cycles were reentered. In 1.7.x this has been optimized so now we're back to the figures you mentioned. The ADC interrupt is rock-steady, so it is not an issue of jitter, rather the reason mentioned above.
3. Hard to evaluate precisely, but like you said, one or two misses should not affect performance significantly, but in any case the upcoming upgrade should have no misses at all, like previous versions.

Now, that is not to say this is an ideal state. What would be ideal is to have the current control loop running in a high-priority interrupt and stuff like CAN frame handling, trajectory planners etc. on a low priority "main" thread. In fact, this is where our development is going, but we'd like to do it in a bit more elegant way than just slapping a Freertos to the firmware, so that we have room to grow in the future.