Weird behavior for SysTick based timer for stm32g483

Question

SysTick usage description

SysTick

We have a custom board based on a STM32G483 MCU (Cortex M4). We use the SysTick as a reference for software timers. The SysTick reload register is set to 0x00FFFFFF so as to have the fewest interrupts. The SysTick is clocked with the CPU clock at 128MHz, which means there is a SysTick interrupt every 131ms or so. The interrupt increments a tick counter by the load value + 1.

#define SYSTICK_LOAD_VALUE 0x00FFFFFFU

static volatile uint64_t _ticks;

void 
systick_interrupt(void)
{
    _ticks += SYSTICK_LOAD_VALUE + 1;
}

We then use the current value register to get the number of clock cycles elapsed in the current counting cycle to compute the current time.

uint64_t 
systick_get_ticks(void)
{
    return _ticks - SysTick->VAL;
}

Software timers

We can then use this value for different software timers that can theoretically count in the order of magnitude of a few clock cycles.

void
timer_start(struct timer *timer)
{
    timer->_start_tick = systick_get_ticks();
}

bool
timer_check_ticks(const struct timer timer, uint64_t duration)
{
    uint64_t difference = systick_get_ticks() - timer._start_tick;
    return (difference >= duration);
}

With function call overheads, it's impossible to be accurate to the tick, but this should still be accurate for longer periods, like 1us (128 ticks) or 1ms (128 000). Sure, the software timer will probably overshoot by some clock cycles, depending on the main loop frequency, but it shouldn't undershoot.

Tests

We were seeing some weird behavior with these timers, so we decided to test them by having the simplest main loop to toggle a GPIO that we could probe.

int
main(void)
{
    // Clock, NVIC, SysTick and GPIO initialisation
    struct pin test_gpio;
    struct timer test_timer;
    timer_start(&test_timer);
    while (TRUE) {   
        if (timer_check_ticks(test_timer, 128000U)) { // 128000 ticks @ 128MHz ==> 1ms
            gpio_toggle(test_gpio);
            timer_start(&test_timer);
        }
    }
}

With this, we were expecting a square waveform with a 50% duty cycle and a 2ms period (500Hz), which is what I was getting most of the time. However, some pulses were sometimes way shorter, for example at 185us. While trying to find the source of the problem, we also noticed that when compiling after any modification would change the length of the shorter pulse, but while the code was executing, this duration didn't seem to change.

We've checked that the core clock does run at 128MHz, the SysTick is configured as we want it, we've written a snippet to check that the SysTick interrupt is triggered at the right frequency, and that the systick_get_ticks() function returns a reliable number. This leads us to believe that the problem comes from the timer code itself, but we can't seem to find the issue.

Code is compiled with clang (--target=arm-none-eabi), STM32 HAL libraries are NOT used

Clifford Clifford · Accepted Answer · 2021-07-08T11:23:54

Consider:

#define SYSTICK_LOAD_VALUE 0x00FFFFFFU

static volatile uint32_t systick_reload_count = 0 ;

void systick_interrupt(void)
{
    systick_reload_count++ ;
}

uint64_t systick_get_ticks(void)
{
    uint32_t reload_count = 0 ; 
    uint64_t ticks = 0 ;
    do
    {
        reload_count = systick_reload_count ;

        ticks = (reload_count * (SYSTICK_LOAD_VALUE + 1)) + 
                (SYSTICK_LOAD_VALUE - SysTick->VAL + 1) ;

    } while( systick_reload_count != reload_count ) ;
}

Here the ISR is simpler (faster) and accessing systick_reload_count is an atomic operation (i.e cannot be interrupted) on this 32-bit device.

The while loop in systick_get_ticks ensures that if the reload occurs during the non-atomic ticks calculation, the new systick_reload_count is obtained and ticks recalculated. The loop should never normally iterate more than twice (you'd have to be interrupted for the 131ms, in which case you have other problems!), so remains deterministic.

An important aspect of this solution is that the calculation is performed in the local copy of the reload count, not on the volatile count itself.