Electronic – Delays using Timer in stm32

cdelayembeddedstm32timer

I am currently trying to achieve delay of 1 uS using timer in stm32 for my application purpose.

SYSCLk is set to 16MHZ LSI and define same for timer clock.
Timer used is a 16 bit timer.
The logic I am using is this.

void delay_us (unsigned int cnt_val)
{    
unsigned long x =0;
unsigned int cnt=0,  psc_cnt = 0;
RCC->APB1ENR |= (RCC_APB1ENR_TIM6EN );

x = (unsigned int)((cnt_val * 1000) / 62);
if(x < 65536)
  {
    cnt = x;
    psc_cnt = 0;
  }
else
  {
    cnt = 0xFFFF;
    psc_cnt = x / 65536;
  }
TIM6->SR = 0x00;
TIM6->ARR = cnt;
TIM6->PSC = psc_cnt;
TIM6->CR1 |= (TIM_CR1_CEN | TIM_CR1_OPM);
while(!(TIM6->SR & TIM_SR_UIF));
RCC->APB1ENR &= ~(RCC_APB1ENR_TIM6EN); 
}

Issue is when i tried to achieve the delay of 1 us i am getting 2.5 us.
I checked it by toggling the gpio.

while(1)
{
GPIOA->ODR ^= GPIO_PIN_5;
delay_us(1);
}

can't understand the reason and looking for the solution.

Best Answer

Look at your delay_us() function.
How many assembler instructions do you think that will compile to?
Don't forget the stack push/pop and return at the end.
Now, at 16MHz, how long do you think that function will take to execute, assuming the while() at the end just falls straight through.

I threw your function into my GCC-based ARM compiler and, without much optimization enabled, it produced 33 instructions.
Considering that your measured 2.5uSec corresponds to about 40 instructions at 16MHz, and adding a few extra instructions for the while(1) loop , the GPIO toggle and the call to the function in your main(), it looks to me as though it's pretty spot-on.

Related Solutions

Electronic – STM32 Timer to control GPIO

A timer interrupt will have significant jitter, unless it is the only interrupt source/handler in the entire system. Clocked devices typically do not behave well when the clock is jittery. Thus, I would personally use a 50% PWM timer instead of a software-generated pulse train, when all I know about the other devices is that it's a "clocked device."

If there's some reason that it's OK for the clock to have jitter on the order of whatever your worst interrupt latency/jitter is, then you could go with either option, although the PWM clearly has less moving parts and thus is less likely to break. Software is not to be trusted if you can do it in hardware :-) (And I say this as a software engineer)

Electronic – STM32: Timer interrupt works immediately

I ran into this with an STM32F105. The STM32F1xx Standard Peripheral Library functions are a bit different than what you are using, but the idea should be the same.

Issuing the TIM_TimeBaseInit() function caused the TIM_SR_UIF flag to become set. I haven't gone back yet to figure out why. Once this bit is set, the interrupt will trigger as soon as it is enabled.

To fix it, after calling TIM_TimeBaseInit(), I immediately called TIM_ClearITPendingBit(). Then I would enable the interrupt with TIM_ITConfig(). This fixed the problem.

My complete initialization routine looks like this:

// Enable the peripheral clock
RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM5, ENABLE);

// Configure the timebase
TIM_TimeBaseInitStructure.TIM_Prescaler = 1;
TIM_TimeBaseInitStructure.TIM_Period = 35999;
TIM_TimeBaseInit(TIM5, &TIM_TimeBaseInitStructure);

// That last function caused the UIF flag to get set. Clear it.
TIM_ClearITPendingBit(TIM5, TIM_IT_Update);

// Configure so that the interrupt flag is only set upon overflow
TIM_UpdateRequestConfig(TIM5, TIM_UpdateSource_Regular);

// Enable the TIM5 Update Interrupt type
TIM_ITConfig(TIM5, TIM_IT_Update, ENABLE);

Best Answer

Related Solutions

Electronic – STM32 Timer to control GPIO

Electronic – STM32: Timer interrupt works immediately

Related Topic