cancel
Showing results for 
Search instead for 
Did you mean: 

stm32g431 setting up PLL and Flash wait state seems to have bricked my nucleos

Lvan .3
Associate II

While trying to get a bare metal environment up and running on the STM32G431 i seem to have found a way to brick both a nucleo-64 with an STM32G431RBT6 and a nucleo-32 with an STM32G431KBT6.

The first one , i switched on the HSE, waited for it to be ready, enabled PWR control, set VOS to 1 and cleared the CR5 boost mode,

i set the HPRE, PPRE1 and 2 divisors all to 1 (same as system clock, i could not find a reason in the datasheet not to.

then i went through the PLL config routine, setting M = 2 (divisor 3), N = 40, for what should end up being 320MHz VCO out, then PLLR divisor to 2 for a system frequency of 160Mhz. I wait for the PLLSYSRDY to come on, after which i set the PRFT, ICEN and DCEN bits in the FLASH ACR register, and finally i set the ACR latency to 5 (should be 5 wait states).

finally i do the set SW/wait till SWS confirms bit.

i can post the exact code later but i first want to describe the phenomenon:

the main program which blinks an LED did not come on, but whats more annoying, the ST-LINK built into the nucleo board doesnt recognize it anymore. i tried hooking up a known-good st-link to the swdio/swclk directly and i get the same behaviour: when i keep the reset button pressed, st-util --probe finds

serial:   303035303030323733303339353130393334333933383338

 hla-serial: "\x30\x30\x35\x30\x30\x30\x32\x37\x33\x30\x33\x39\x35\x31\x30\x39\x33\x34\x33\x39\x33\x38\x33\x38"

flash:   0 (pagesize: 2048)

 sram:    32768

 chipid:   0x0468

 descr:   G4 Category-2

if i don't keep the reset button pushed i get

Found 1 stlink programmers

 serial:   303035303030323733303339353130393334333933383338

 hla-serial: "\x30\x30\x35\x30\x30\x30\x32\x37\x33\x30\x33\x39\x35\x31\x30\x39\x33\x34\x33\x39\x33\x38\x33\x38"

 flash:   0 (pagesize: 0)

 sram:    0

 chipid:   0x0004

the interesting difference is that the flash size looks to be zero.

(thinking that this might be a limitation of the open source stutil, i tried installing STMCubeProg again, but like when i last tried a few years ago, the installation requires manual copying of java runtimes, and when you get it to run, it just crashes on these boards. it can connect to undamaged nucleos, but both of these broken boards make the STMCubeProg app crash when i click connect).

so having a nucleo32 lying around i proceeded a bit more careful: first i used the HSI instead of HSE to be sure i start with a working clock source. i then configured the PLL to come up to 72MHz and i set the HPRE, PPRE1 and PPRE2 to 2 so all peripherals were clocked at 36MHz.

Then i set the flash wait states to 5, like last time.

Interestingly, the main blinkyled program does come on, and it blinks at the expected frequency, but the ST-Link can't see the board anymore either.

trying to make the nucleo-48 boot into the boot0 bootloader so that it wouldnt even pass my ResetHandler is unsuccessful.

it seems that by setting the flash parameters i have made some irreversible changes. but i have not touched the option bytes. is that even possible? could it be that it always boots through my ResetHandler, messes up the FLASH access, so that the ST-Link finds an already misconfigured device and can't run anymore?

but then why can it read the chip ID?

i'm baffled and hesitant to brick my remaining nucleo board before i know what to look for.

12 REPLIES 12
thanks for the answers so far. seems like i /should/ be able to boot into a sane state. ill try to get a working stmcubeprog setup first then (not on mac) and report back
Piranha
Chief II

Are the elements (registers) of your custom structures (struct RCC_Type, struct FLASH_Type, etc.) volatile?

The NOPs in the loops are useless. They only waste a FLASH space.

Lvan .3
Associate II

yes they are volatile

the nops are a resting point for the debugger and part of our coding convention.

while(someting);

is an error-prone thing to write and annoying to step though in a debugger, so not allowed in my companies coding convention.

a single byte in 128k of flash memory is a price well worth it compared to 2 days of debugging a missing semi-colon.