Timing of Stepper ISR is different with ARPE-BIT at STM32F756

[AndreLukas121]

Hi,

We put the grblHAL under a lot of stress by driving small travel distances at regular intervals. We noticed that the stepper ISR kept "waiting".

This can be explained by the fact that the stepper ISR (ISR_CODE void ISR_FUNC(stepper_driver_interrupt_handler)(void) in stepper.c) writes the value for the auto-reload register itself and the ARR value is adopted immediately (see static void stepperCyclesPerTick (uint32_t cycles_per_tick) in driver.c). However, in some cases the execution time of the stepper ISR (in Picture 1 the blue arrow) takes longer than the calculated ARR Value 2 so that the counter from the timer counts up to the maximum value.

Picture 1: "WAIT" for next event

A possible error correction with Auto-Reload Preload Enable (ARPE-BIT):

The bit only changes the ARR value with the update flag at each overflow event. However, this also changes the timing.
In the next two images we can see the differences in timing. In the second ISR we change the ARR value 1 to ARR value 2. If ARPE = 1 this means that only the next ISR will be affected by the change and if ARPE = 0 (current implementation), the ISR that is still running. differ between the timing in the second ISR we change the ARR Value to ARR-Value 2. This influenced the next ISRs.

Picture 2: ARPE-Bit = 0

Picture 3: ARPE-Bit=1

Finaly, we a litte bit confused what the actual behavior should be and whether it has an impact on repetition accuracy.
And if the ARPE bit isn't a solution, does anyone have an idea how to solve it instead?

Can someone help us. Thank you in advance.

regards
Andre

[terjeio]

However, in some cases the execution time of the stepper ISR (in Picture 1 the blue arrow) takes longer than the calculated ARR Value 2 so that the counter from the timer counts up to the maximum value.

Has this been observed? If so with which settings and gcode? And what is the symptom when there is unexpected behaviour?
The timer is used in count down mode so should never count outside 0 to the latest ARR value set.
I have occasionally seen very long step intervals coming from the core, this is why there is an upper limit imposed in the driver. But I doubt this is an issue - at least noone has reported anything related to it.

And if the ARPE bit isn't a solution, does anyone have an idea how to solve it instead?

Lower the step rate? Step pulse width too long and should be reduced?
If the step rate is too high the driver crashes due to reentering the interrupt handler, this can be detected and should perhaps result in halting the job. I can run 3 axes with step rates > 300KHz on the bench, this with a release build (-O2). If testing with a debug build the max rate is significantly lower, around 100KHz it seems.