STM32F207 Timer counter fails to increment

[AJose.2]

I am developing an application on STM32F207ZC MCU with the internal oscillator as the clock source. I am trying to use two hardware timers(Timer 4 and Timer 9) to generate PWM signals in GPIO pins. I am able to produce the PWM signals with both timers on the development board.

Now I am trying to flash the code on a custom board. With the custom board, timer 4 failed to produce any PWM signal while timer 9 was able to produce the required PWM signals. I verified that the GPIOs I used were functional by toggling them.

On further debugging, I noticed that the Timer 4 count register(htim4.instance->cnt) was zero the entire time, while the timer 9 count register was getting incremented. I check the clock initialization for the timer and it was fine.

The errata sheet mentioned using DSB instructions to induce delays while initializing AHB clocks. I tried this change and read back the clock enable bit to verify if the clock was enabled. The timer enable macro was also getting called from the HAL drivers.

I also tried lowering the clock frequency in the AHB1 clock bus. The behavior was the same

Is there something else that I haven't checked yet?

[waclawek.jan]

Read out and check/post content of TIM4 and TIM9 and the relevant GPIO registers.

JW

[Tesla DeLorean]

I haven't use an F2 in eons, but if the TIM is in the RM, it should be viable. The APB and AHB clocks do need to be functional. And it's perhaps advisable to enable all the clocks first, then the pins, then the peripherals. The HAL / Cube model seems to kitchen-sink stuff, so the flow was less clean than with the SPL.

The RCC clock routines should do a read-back after write, making sure the write-buffers committed, and buying 4 or more cycles.

You've checked those, you've checked the enable on the timer side. Look to be going in the right direction.

For the pins, check the AF values map properly. The Data Sheet should have the primary/controlling list.

As Jan indicates doing a register dump of whats actually going on is the best to understanding what we're working with.

[Piranha]

> I also tried lowering the clock frequency in the AHB1 clock bus.

Increasing the AHB/APB prescalers makes the delay issue worse - the delay must be longer.

ES0005 Rev 11, 2.1.11 Delay after an RCC peripheral clock enabling

Use the DSB instruction to stall the Cortex-M CPU pipeline until the instruction is completed.

This is just plain wrong. None of the CPU barrier instructions (DSB, DMB and ISB) enforce or guarantee anything related to the peripheral buses.

@Imen DAHMEN​ this is a nonsense and must be removed.

[AJose.2]

I tried using nop instruction as well.

#define __HAL_RCC_TIM4_CLK_ENABLE()   do { \

                    __IO uint32_t tmpreg = 0x00U; \

                    SET_BIT(RCC->APB1ENR, RCC_APB1ENR_TIM4EN);\

                    /* Delay after an RCC peripheral clock enabling */ \

                    tmpreg = READ_BIT(RCC->APB1ENR, RCC_APB1ENR_TIM4EN);\

                    UNUSED(tmpreg); \

                    } while(0)

The value of tmpreg was reading correct as well. Still the CNT register is not getting updated.

[Piranha]

That macro also doesn't guarantee the required delay, which depends on bus clock cycles of the particular peripheral. RCC is on AHB1, but TIM4 is on APB1. As you already know, most of ST's code is broken. At least for testing purposes ensure that there is a significant delay after enabling that clock. For example, HAL_Delay(1); is enough.