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.

[AndreLukas121]

Has this been observed? If so with which settings and gcode? And what is the symptom when there is unexpected behaviour?

A: Yes, we have observed this unexpected behavior. The motor runs and sometimes the motor stops for about 39 seconds and the stop time of 39sec is constant, meaning every time we stop, it really stops for 39sec. Here is the Gcode and the setting attached.

The GCode is generated automatically with this function.

YPos = 0.0
XPos = 0.0

BEGIN_LOOP
YPos = YPos + 10 // 1 cm
send G0XY

IF YPos > 450 THEN
XPos = XPos + 100 // 10 cm
YPos = 0
ENDIF

IF XPos > 1000 THEN
XPos = 0
ENDIF

END_LOOP

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.

A: We have not seen that the configuration of the timer is in countdown mode. Can you please show where the config bit for the countdown is set.

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.

A: The step rate is 41KHz I think that is low enough.

2024-11-05-settings.txt

[terjeio]

The motor runs and sometimes the motor stops for about 39 seconds and the stop time of 39sec is constant

To count from 0 to overflow in 39s implies a timer clock of ~110Mhz, however it runs at 27MHz.

The GCode is generated automatically with this function.

So this means it happens randomly, not every time the same move is executed?

Can you please show where the config bit for the countdown is set.

Here.

[AndreLukas121]

To count from 0 to overflow in 39s implies a timer clock of ~110Mhz, however it runs at 27MHz.

A: Yes, CLK-freuqency is 108MHz.

So this means it happens randomly, not every time the same move is executed?
A: Yes, it happens randomly.

Thanks, we are using the GRBL_Build: 20220906 There is no definition of the countdown mode there. So I think that in newer builds there are no problems in that direction.