In my program I have an input which is turning on and off. If the input is not turn on in 3 second I need to detect this. I'm using Timer14 with interrupt. If the input is turn on, the timer is stopped, reseted and start counting from the beginning. If not (timer count to the end) the timer SHOULD give me an interrupt.
My problem interrupt. When I start the timer, It immediately gave me the interrupt after that I never get interrupt from timer again.
In my code I use:
HAL_TIM_Base_Start_IT(&htim14); // Start timer __HAL_TIM_SET_COUNTER(&htim14, 0); // Reset tiemr if input was turnOn HAL_TIM_Base_Stop_IT(&htim14); // Stop counter
Did I missed something... maybe interrupt flag reset? or something else?
Thank you for any answer.
Prior to starting the timer, but after initialization, clear the update flag.
No, just prior to starting the timer, but after initialization.
It is cleared within HAL_IRQHandler.
If you're implementing your own IRQ handler then yes you'll need to clear it.
The reason to clear the update flag is, that
Thank you for your time and explanation but I'm still a bit confused.
I use CubeMX and HAL library, so the timer is initialize automatically in section /* Initialize all configured peripherals */.
While the execution of my program I Start and Stop (HAL_TIM_Base_Start_IT and HAL_TIM_Base_Stop_IT) the timer for several times.
Do I need to to use __HAL_TIM_CLEAR_IT everytime before start the timer again?
I don't use Cube, but it's open source, so you can look up what do the functions you mention, actually do.
You can also single-step them in the debugger and observe, if the interrupt flags get set - but be sure to set the respective bits in DBGMCU to avoid running of the timers during debugging.
> If I would like to do it in CMSIS what should I do ?
Short answer: look at the ST libraries and examples and do the same.
The timers are vendor-specific (ST) devices, memory-mapped. To access vendor defined memory areas CMSIS does not define anything special and relies on the "common sense" of C compilers. Device registers are declared as volatile structures. All decent compilers for ARM know what means volatile and do what one could expect. Often you can see in the ARM own CMSIS source device writes followed by __DSB(). __DMB() is another CMSIS memory barrier you need to know about. The ST library uses the same for writes to vendor device registers - plain C read/writes to registers and barriers - but the barriers alone may be not providing enough delay in many cases. It has been disused in this forum. TL;DR
ST library also has macros (READ_REG, WRITE_REG, MODIFY_REG...) which are trivial, except of their ATOMIC variant (ATOMIC_MODIFY_REG...).