AnsweredAssumed Answered

STM32L4 LPTIM : CNT EXCEEDS ARR & INFINITE IRQ HANDLER PROCESSING(FIXED)

Question asked by quan.ding on Nov 28, 2015
Latest reply on Jan 30, 2017 by Martin Guthrie
First of all, forgive my poor English :)
As title indicated,I want to propose two issue I confront in my work.
Before that,I would like to introduce the function I was supposed to achieve briefly. In my project, I used the example project which includes the FreeRTOS as the prototype to code my own function.The example project uses the SYSTICK register to count ticks which will stop when the MCU enters deep sleep mode(more accuratly, stop 1 mode).So I re-code the function using LPTIMER 1 instead. In fact , I don't care too much about how precisely the ticks counted in deep sleep mode is. It may drift a little along time, so the conpensation of time drift induced by stoping and re-configuring the LPTIMER is not realized.Fortunately, the code works, and the system run well....uh...seemed well.

Before going into deep sleep mode, I configure the register ARR to the next wakeup time, the same as the example code did so. Step 1: get CNT value, Step 2: minuse CNT from ARR to seem how many counts remain in current tick. Step 3: calculate the ARR value for wakeup(BTW, the enable and disable of LPTIMER is under the instruction of the the Manual).

the question is, the CNT is bigger than the ARR sometimes, which makes  (ARR - CNT) to be a negative number,and that is a very large positive number in an uint32_t type varialble. And this makes me confused. HOW CAN CNT EXCEEDS ARR? Did I do any thing wrong with LPTIMER, or is there any thing I should pay more attention to when configure the LPTIMER registers?

Another Question is :
Sometimes, my code run to an infinite processing of LPTIM1's IRQ Handler, which blocks the whole FreeRTOS threads.I checked the LPTIMER's register, the configurations are all correct.It's weird, and I want to know had anyone confronted the same thing as I did? How can I make all the things right?

ANSWER:
The reason why CNT exceeds ARR is that ARROK bit int ISR is not set while another write to ARR occurs. Restrictly follow the instruction of configing ARR will avoid this problem. Don't forget to clear the ARROK bit.

Outcomes