I am using one of the 32 bit timers to measure intervals for fault protection on a HV pulse modulator. I have an interrupt on EXTI that captures both leading and trailing edges of the command pulse. In the service routine, I simply store the latest uptime and downtime to calc the pulsewidth and period....pretty simple. The pulsewidth is pretty small, so I use the free-running SYSTICK (400 MHz) for pulsewidth, but it is only 24 bits, so I need to use a 32 bit timer for the pulse period, and do so at 50 MHz.
I initially coded this with TIM2, and it worked perfectly. Then I realized that I needed to use TIM2 elsewhere because I already wired a different time-critical signal to the TIM2.ETR pin (the ETR interrupt latency is far less than the EXTI latency). So I switched my code to use TIM5 for the period. This did not work. It bounces around semi-randomly, and by appearances is acting like a 16 bit timer.
I switched to TIM23, and again it works perfectly. I searched this website, and found other entries complaining of TIM5 operation, one specifically saying it reverted to 16bit after a rollover. I do not find any reference to this on the errata sheets. I am fine with my TIM23 fix, so I don't have a problem, but if this is a hardware bug, it should be on the errata.
I am hard coding in assembly, no HAL, no CUBE. My init code is the same for all three cases:
set TIMx_PSC to 3 (prescale = 4 with 200 MHz base for 50 MHz ticks)
set TIMx_ARR to 0xFFFFFFFF (max reload, simply free run the timer)
set TIMx_EGR to 1
set TIMx_CNT to 0
set TIMx_CR1 to 81
The appropriate RCC reset pin is strobed and the RCC enable pin is on, of course.
In the interrupt service, I am simply capturing TIMx_CNT and saving to SRAM for later inspection.
Is this a known feature, or am I doing something ***?
Thanks!
Jeff Casey
