I am currently working with an STM32F407 processor and trying to emulate it, and testing the timers I notice the behaviour is not as expected with respect to the limits configuration.
The update event (to generate an interrupt or DMA action) is sent when the counter reaches the overflow (or underflow when downcounting)
In upcounting mode, the counter counts from 0 up to and including the auto-reload value (the content of the TIMx_ARR register), then restarts from 0 and generates a counter overflow event (See Figures 137 - 142 in the reference manual).
In downcounting mode, the counter counts from the auto-reload value down to and including 0, then restarts from the auto-reload value and generates a counter underflow event (See Figures 143 - 147 in the reference manual).
Expected behaviour
This behaviour differs from that implemented in the UpdateHandlers, which are part of the BaseClockSource.cs file. The current common implementation notifies the clockEntry event when the limit is reached in upcounting mode and when zero is reached in downcounting mode, and not when an overflow or an underflow occurs, respectively. That means, the conditions for notifying the clockEntry event (in the case of an STM32) would be "greater than" and "less than" instead of "greater than or equal" and "less than or equal".
Do you plan to address this issue and file a PR?
Since this implementation is done in a common file, shared by different architectures, I do not have enough knowledge to understand the implications of this change. Maybe we can open a discussion on possible solutions if necessary, such as defining this behaviour by configuration and selecting the UpdateHandler considering it.
I am currently working with an STM32F407 processor and trying to emulate it, and testing the timers I notice the behaviour is not as expected with respect to the limits configuration.
Description
Following the description found in the reference manual: https://www.st.com/resource/en/reference_manual/dm00031020-stm32f405-415-stm32f407-417-stm32f427-437-and-stm32f429-439-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf
Expected behaviour
This behaviour differs from that implemented in the UpdateHandlers, which are part of the BaseClockSource.cs file. The current common implementation notifies the clockEntry event when the limit is reached in upcounting mode and when zero is reached in downcounting mode, and not when an overflow or an underflow occurs, respectively. That means, the conditions for notifying the clockEntry event (in the case of an STM32) would be "greater than" and "less than" instead of "greater than or equal" and "less than or equal".
Do you plan to address this issue and file a PR?
Since this implementation is done in a common file, shared by different architectures, I do not have enough knowledge to understand the implications of this change. Maybe we can open a discussion on possible solutions if necessary, such as defining this behaviour by configuration and selecting the UpdateHandler considering it.