STM32 F3 Pll stuck

[Walter3]

I’ve an weird issue with one of my boards.

On the code where the clocks are initialised(it’s the default code generated by Cube), the mcu gets stuck on the line, HAL_Pll_Enable and it continuously restarts the mcu every 6ms. But the same hex file, works good in another board.

For details, I use an external crystal set to run at 12MHz and once the mcu is on and if I put a breakpoint, I can monitor the output of the crystal, Rcc_osc_out and Rcc_osc_in to be precisely 12MHz.

if i configure the system clock to use HSE instead of PllClk, then it works, but I want the board to work with pll to a frequency of 72MHz. This is the first time it’s happening and I’ve no clue where to pinpoint the issue since the core keeps restarting without providing any fault reports or setting some error bits. And when it restarts, I get this warning during debug mode, “cannot access target.�? Can someone shed some light on this issue?

thanks !

[waclawek.jan · Accepted solution]

FLASH latency set properly?

Analog VCC and ground connected and decoupled properly?

JW

[Walter3]

Yes, Flash Latency is set to 2WS.

And as far as i can see, the Analog VCC and Ground are connected and decoupled properly.

[Tesla DeLorean]

It is indicative of a power failure/brownout. Perhaps scope the pin during the issue cycling, and double check regulators and bulk capacitance.

[waclawek.jan]

> scope the pin

And by "pin" here Clive means the pin, literally, directly on the package. And not only VCC(A) but GND(A) too.

Also, what exactly do you mean by "HAL_Pll_Enable"?

JW

[Walter3]

I monitored the voltage level at Nrst pin during this issue and it seems to go to zero and then back to 3.3. When I erase the application from STM flash memory, then the Nrst pin is stable at 3.3 volts. I’ve this issue only after I load the hex file.

@jan, I’m referring to the macro __HAL_PLL_Enable; placed in systemclock_config() function. Once my debug trace reaches this point, the connection to cortex is lost and I get error during debugging.

i believe this macro is somehow causing an issue for internal PLL, perhaps corrupted base memory of peripheral?

Again, as long as I don’t enable the PLL and route system clock to use HSE or HSI instead of PLLClk, my application works.

[waclawek.jan]

NRST is a bidirectional pin, it pulses because of some internal cause of reset.

Monitor the supply pins.

Do you have watchdog enabled, either in software or through the options (WDG_SW)?

Which mcu in particular? Tell us also details about the surrounding hardware (mainly supply). What's the supply voltage? Are all VDD and GND pins connected? Did you verify there is no bad solder joint? Is NRST floating?

Read out and check/post the RCC and FLASH registers' content just before executing that macro. Also post content of the OPTION bytes.

[Walter3]

Thanks a lot for the tips, I found the issue. The voltage at vdda was much lower than vdd and it seemed to be an issue with the layout. This damaged the mcu and I had couple of boards dying coz of it.

[waclawek.jan]

If resolved, can you please mark as such.Thanks.