STM32 F3 Pll stuck
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 09:45 AM
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 !
Solved! Go to Solution.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 01:17 PM
FLASH latency set properly?
Analog VCC and ground connected and decoupled properly?
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 01:17 PM
FLASH latency set properly?
Analog VCC and ground connected and decoupled properly?
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 02:09 PM
Yes, Flash Latency is set to 2WS.
And as far as i can see, the Analog VCC and Ground are connected and decoupled properly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 02:27 PM
It is indicative of a power failure/brownout. Perhaps scope the pin during the issue cycling, and double check regulators and bulk capacitance.
Up vote any posts that you find helpful, it shows what's working..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 02:35 PM
> 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-15 10:27 PM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-16 12:58 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-16 11:32 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2018-08-16 01:40 PM
If resolved, can you please mark as such.Thanks.