Problem with TIM9 on NUCLEO-F767ZI board.

[BVu]

I'm using the NUCLEO-F767ZI board. I can get PWM to work with any timer except TIM9. The debugger shows TIM9's ARR, PSC, CCR having the values i set them to. After the call to HAL_TIM_PWM_Start (&htim9, TIM_CHANNEL_2) is made, the CEN bit in CR1 is set. But the CNT register always shows zero. That means the timer doesn't start counting for some reason. All other timers work just fine. Strange problem! Has anyone seen this?

[BVu]

If I disable AutoReloadPreload then TIM9 starts counting fine once CEN is set. If AutoReloadPreload is enabled then the timer never starts counting. Look like it's buggy behavior to me.

[BVu]

For (TIM9/TIM10/TIM11/TIM12/TIM13/TIM14), in case of preload enable, before starting the counter, you have to initialize all the registers by setting the UG

bit in the TIMx_EGR register. This is documented in the Reference Manual.

[waclawek.jan]

Nice catch, turbonella!

The root of the issue is that ARR in these TIMs' registers in this model (and also in other 'F7) is not set to maximum (0xFFFF), but to 0, when the timer does not run.

 [EDIT] I looked into an old version (rev.5) of the 'F74xx/75xx RM. Also, the findings on 'F769 don't support this theory, see my later posts. [/EDIT]

> This is documented in the Reference Manual.

Can you please point out exactly where?

JW

[waclawek.jan]

I've just downloaded RM0410 Rev 4 and both 27.4.10 TIM9/TIM12 auto-reload register (TIMx_ARR) and 27.5.9 TIM10/TIM11/TIM13/TIM14 auto-reload register (TIMx_ARR) say that the default value is 0xFFFF. That wouldn't explain the above behaviour then.

@BVu​ , or anybody else, can you please read out the ARR value of these timers after they have been enabled in RCC, but before any explicit initialization?

Thanks,

JW

[BVu]

I disable TIM9 AUTORELOAD_PRELOAD so that i can read the active reg directly. The debugger stops at main(). I single step past SystemClock_Config() which is where RCC is init, and followed TIM9 ARR when i stepped. ARR started out being 0x0 and stayed 0x0. Look like the the default value is 0x0 and *not* 0xFFFF.

Thanks,

[BVu]

BTW, in the original post, i said "I can get PWM to work with any timer except TIM9". I instantiated the timers, say TIM10, TIM12, with CubeMX. By default AUTORELOAD_PRELOAD is disabled, and that's why they worked. When i went back, and compared the way i set up TIM9 versus the other timers, i realized that the difference is AUTORELOAD_PRELOAD. The ARR default is 0x0 instead of 0xFFFF is true for TIM9. It may just be true for all of TIM9/TIM12/TIM10/TIM11/TIM13/TIM14 Don't have time yet to check them all out yet.

[waclawek.jan]

@SToma​ was so kind he tried this on his 'F769 Disco, and TIM9 ARR reset value was indeed 0xFFFF as the RM says. He also tried to set ARPE and then set CEN, and CNT was running as expected.

As the 'F767 and 'F769 silicon is identical, AFAIK; I don't know how to explain turbonella's observation...

JW

[BVu]

I don't know how to explain it either. I first thought the silicon was somehow damaged. So i tried on a brand new out-of-the-box NUCLEO-F767ZI, plus a F767ZI custom board, and they behave the same, i.e. ARR reset value is zero. But it works for me now, as long as i set UG bit before calling HAL_TIM_PWM_Start (). Hopefully this thread will help someone else.

Thanks,

[BVu]

Found the explanation (this is an itch i got to scratch):

MX_TIM9_Init()->HAL_TIM_Base_Init()->HAL_TIM_Base_MspInit(). This is where the TIM Clk is enabled. At this moment, TIM ARR goes to its reset value of 0xFFFF.

Then HAL_TIM_Base_Init()->TIM_Base_SetConfig(). This is where the TIM registers are loaded with the default values as indicated in CubeMX including the ARR value. If ARR is zero then ARR is set to zero here. The last thing TIM_Base_SetConfig() does is to set UG bit to force updates of the active registers.

In my case i left the ARR value in CubeMX at zero. By the time my application code load ARR and start the timer, it's too late since the timer never run (in case of preload enable). To get this to work, it's safe to specify ARR of anything but zero in CubeMX. The correct behavior of TIM_Base_SetConfig() is to load ARR with the reset value of 0xFFFF, or not to change ARR at all, if the initial value (from CubeMX) is 0x0.

Thanks,