LL_TIM_*() calls take too much time.

Question

I am having a problem with a timer. I use CubeMX LL drivers, with basic time-base timer configuration.

STM32L100RCT6, TIM6 and TIM7. Core Clock = 32MHz, PCLK1 (TIM6 and TIM7) = 32MHz

Prescaller = 31, which should set timer to tick at 1us. ARR value is set to max, 65535, interrupts are disabled.

Although my timer does tick at 1us, starting and stopping timer adds another few microsecond, which is unacceptable for my application. I added GPIO writes (directly using registers) and check timings with logic analyzer.

Here is the pseudo-code of my test:

// start timer
<GPIO HIGH>
LL_TIM_SetCounter(TIM6, 0);
<GPIO LOW>
LL_TIM_EnableCounter(TIM6);
<GPIO HIGH>
while(LL_TIM_IsEnabledCounter(TIM6) == 0) {};
<GPIO LOW>
 
// poll timer until value match
while(getUsDelayTimerValue() < 99) {};
<GPIO HIGH>
 
// stop timer
LL_TIM_DisableCounter(TIM6);
<GPIO LOW>

I assume that any of LL_TIM_x call would be in a range of a few nanoseconds, or at least far below us range, since they mostly resolve into single register writes. The problem is, that in reality, this calls take way more time than they should:

// start timer
LL_TIM_SetCounter(TIM6, 0); -> 250 ns
LL_TIM_EnableCounter(TIM6); -> 291.67 ns
while(LL_TIM_IsEnabledCounter(TIM6) == 0){}; -> 583.33 ns
 
// poll timer until value match
while(getUsDelayTimerValue() < 99){} -> 100.542 us
 
// stop timer
LL_TIM_DisableCounter(TIM6); -> 791.67 ns

... which altogether takes: 102.458 us, instead of 100 us as expected.

What am I doing wrong or is there a thing I missed?

This is the code CubeMX generate for timer initialization:

void MX_TIM6_Init(void){
 LL_TIM_InitTypeDef TIM_InitStruct = {0};
 /* Peripheral clock enable */
 LL_APB1_GRP1_EnableClock(LL_APB1_GRP1_PERIPH_TIM6);
 
/* TIM6 interrupt Init */
 NVIC_SetPriority(TIM6_IRQn, NVIC_EncodePriority(NVIC_GetPriorityGrouping(),1, 0));
 NVIC_EnableIRQ(TIM6_IRQn);
 
TIM_InitStruct.Prescaler = 0;
TIM_InitStruct.CounterMode = LL_TIM_COUNTERMODE_UP;
TIM_InitStruct.Autoreload = 0;
LL_TIM_Init(TIM6, &TIM_InitStruct);
LL_TIM_DisableARRPreload(TIM6);
LL_TIM_SetTriggerOutput(TIM6, LL_TIM_TRGO_RESET);
LL_TIM_DisableMasterSlaveMode(TIM6);
}

And this is how I further init timer prescaller and autoreload.

void initTimer(void)
{
 NVIC_ClearPendingIRQ(TIM6_IRQn);
 LL_RCC_GetSystemClocksFreq(&clocks);
 uint32_t prescaller = US_DELAY_TIMER_TICK * clocks.PCLK1_Frequency / 1e6 - 1;
 assert_param(prescaller < 65535);
 LL_TIM_SetPrescaler(TIM6, prescaller);
 
 LL_TIM_SetAutoReload(TIM6, 65535);
 LL_TIM_ClearFlag_UPDATE(TIM6);
 LL_TIM_EnableIT_UPDATE(TIM6);
 LL_TIM_GenerateEvent_UPDATE(TIM6); // prescaller values is updated at the next update event
 _waitUntilUpdate(TIM6);
 LL_TIM_ClearFlag_UPDATE(TIM6);
 
 NVIC_DisableIRQ(TIM6_IRQn);
}

berendi · Accepted Answer

These timing seem realistic to me, except the last one with 791 ns.

Consider a sequence of flipping a bit in a control register, and setting the PA6 pin high

TIM6->CR1 |= TIM_CR1_CEN;
GPIOA->BSRR = 1<<6;

Assuming that both peripherals were accessed recently, so their addresses are already held in registers (e.g. r2=TIM6, r3=GPIOA), this would translate to 5 machine code instructions (if optimizations are turned on)

ldr r0, [r2]
orr r0, #1
str r0, [r2]
mov r0, #64
str r0, [r3,#0x18]

loads and stores can take 2 cycles, mov and orr each take 1 cycle, flash latency could stall it a bit too, so 9 cycles seem like a worst case scenario but still plausible. If you'd drop the GPIO stuff, you can excpect almost the half of the overhead to go away.

The last operation taking 791 ns is puzzling, perhaps you can take a look at the disassembly.

You might be able to shave a few cycles off here and there. First of all, use neither HAL nor LL especially when there are tight timing requirements. Note that in the above example, all other bits of CR1 are 0, so writing

TIM6->CR1 = TIM_CR1_CEN;

instead of what LL_TIM_EnableCounter() does makes the time-consuming load from a peripheral register unnecessary, saving 2 or maybe 3 cycles due to pipelining. Using the HAL_ or LL_ functions makes spotting these kinds of unnecessary operations harder. (Is there any possible benefit of using LL?) Check every operation in the reference manual to see whether it's necessary at all. There is no need to check that the counter is enabled after enabling it, so here goes another 500 ns of overhead. You don't even have to start and stop the timer every time, just leave it running, and reset the counter whenever the start of an interval has to be marked.

It should be possible to have an overhead of about 400-600 ns, but I don't think it would go below that. If that's still unacceptable, consider instead what do you need the delay for in the first place. Can perhaps a timer do the task on its own, or trigger a DMA transfer or two to do the job?

S.Ma · Answer

To me the implementation is wrong and will cause lots of debug and side effects.

If the SW timings is nearly to its limit, this is a red alert.

Say you implement USB with interrupts at top priority, then your implementation will malfunction randomly.

Better use the timer(s) HW features effectively. Use HW resources as much as possible and make sure the SW has enough margins for all that is running on the core.

However it is still possible to learn this the long and hard way. :D

And you'll start to discover your code is compiler optimisation dependent. Go figure...

Sign up

Login with SSO

Login to the community

Login with SSO