1
\$\begingroup\$

On my STM32F769I Discovery board I tried BlinkLED example, using Eclipse IDE (xPack toolchain, OpenOCD, ...). Debugging fails when frequency was adjusted (original code) to 192 MHz (later on boosted in the example).

The code line where debuggers fails is moment of writing to RCC_CFGR register.

When I change frequency to 96 MHz (the only line I changed), debugger successfully passes the line mentioned and proceeds to "main" function. The board has supply from my laptop's USB output (no external supply).

What could be the culprit of such behavior ?

\$\endgroup\$
1
\$\begingroup\$

RCC_CFGR is the register that switches the CPU to a different clock. If the MCU stops working after that, there's something wrong with the new clock source.

The clock tree diagram in figure 13 (section 5.2) of the STM32F76x reference manual shows the various clock sources. You're configuring the AHB clock, which feeds into the CPU. Here are some things that can go wrong:

  • The PLL is set to use an external crystal (OSC_IN) but you only have the internal 16 MHz clock (HSI), or vice-versa.

  • The PLL dividers are not set correctly, so your AHB frequency is too high.

  • The AHB prescale divider is not set correctly, so your AHB frequency is too high.

  • Some other clock divider (like APB) is not set correctly, causing a fault.

  • Your AHB divider is set correctly, but the PLL output frequency (SYSCLK) is too high (above 216 MHz).

Before the write to RCC_CFGR, you can check whether the PLL is locked by looking at the PLLRDY bit in RCC_CR. If the bit is 0, trying to use the PLL will cause a fail.

I made a simplified version of the clock tree diagram to help illustrate what's going on:

Clock tree diagram with only HSE, HSI, PLL, AHB, and APB

If you post the modifications you made to the code I might be able to tell you more, but this should get you started.

\$\endgroup\$
3
  • \$\begingroup\$ Yes, it should be good for the start. Maybe I inadvertently expected for example to work correctly with no intervention. I've already red in reference manual, what you mentioned and also surveyed the code, however I'm going to do it more thoroughly once more. What I changed was PLLN multiplication factor (from 384 to 192). Code, later prints frequency of 96MHz. \$\endgroup\$ – Djole Apr 24 at 5:29
  • \$\begingroup\$ Even if the values of the config bits are correct, the sequence/order of applying them may also be important. \$\endgroup\$ – Tagli Apr 24 at 6:17
  • 1
    \$\begingroup\$ Although the board is not with me at the moment, I think I found an error. There are 4 writes at RCC_CFGR. First one writes AHB prescaler (to 1), next one is switch to PLL as source, then follow writes of APB1/2 prescalers. So after switching to PLL, APB1/2 have their reset values (devide by 1), and having AHB at 192MHz, clocks APB1 & 2 broke their limits. Program doesn't reach the point of writing correct APB1/2 values. Which means both, Adam and Tagli were right. \$\endgroup\$ – Djole Apr 24 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.