cancel
Showing results for 
Search instead for 
Did you mean: 

Stm32f4: Program Erased on Power Cycle -- SOLVED

dlepe
Associate II

First post on the forum...

I’m currently programming a custom PCB with an Stm32f446ret6 for an uC. Using an SWD interface and System Workbench the program uploads fine. However when I disconnect the board, and then hook it up to an external P.S. the program doesn’t run.

I’ve done a fair bit of searching on the forums to try to figure out what the trouble might be. Here’s my current setup...

Boot0 -> 10k resistor to GND

Nrst -> 0.1uF (100nF) cap to ground

I also have an stmf446re Nucleo board that I used for prototyping, and it has the same issue of the program being erased on power cycle. I have checked the STlink firmware and it is on the most current version. Hopefully someone’s come across something sililar.

Cheers

1 ACCEPTED SOLUTION

Accepted Solutions
dlepe
Associate II

UPDATE: Solved the Issue

The problem wasn't hardware related. I had a few lines of code from a while back that initialized the DWT cycle counter.

Old Code:

DWT->CYCCNT = 0;

DWT-> CTRL |= 1;

New Code:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;

DWT-> CYCCNT = 0;

DWT-> CTRL |= DWT_CTRL_CYCCNTENA_Msk;

I did a bit more research on how to use stutility and verified that the program was actually still in flash after a power cycle, per Clive's suggestion. Then began the hunt for the troublesome lines of code.

View solution in original post

6 REPLIES 6

Is it being erased or just not running? Two different boards would make you super unlucky.

More probable it is stuck in a while() loop for either a HardFault_Handler() or Error_Handler()

I'd add some code in the Reset_Handler to toggle a GPIO or output via a USART

Check the voltage on the VCAP pins. Check the voltage on NRST. Inspect memory with ST-LINK.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Clive,

thanks for the comment! I’ll definitely do some checking. Maybe I was wrong to say the flash was erased. I’m new to using System Workbench.

After I power cycle the boards however, I press the reset button on the nucleo and pull the nrst on my custom stm32f4 pcb to GND, then the PA5 led (green on the nucleo) goes high. The simple test program I wrote has the PA5 led blinking at 5Hz, so I assume that the pragram was erased.

When I initially program the board, I have the boot0 pulled to GND with the 10k resistor. I wouldn’t have the set the board to system memory to upload the program initially right?

Make sure you enable the GPIOA clock, the debugger might do this for it's own reasons.

Comment out SystemClock_Config(); the system will just run from the 16 MHz HSI it initially started from.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dlepe
Associate II

Clive,

Ran through the code to double check, and the voltage across VCAP looks fine, and it doesn't look like there's a software reset coming from the SWD. Here's a picture of schematic I'm currently using, it's not shown but there's a 0.1uF cap on NRST.

I'll attach the code I'm using too. I took your suggestion and inserted a line that toggled LD2 in the error handler, as well as in the main while(). I also commented out the systemclock_config(). Running the code on my nucleo, I first upload the program... Then I disconnect the board and power with an external 5V on E5V (just to make sure that the onboard STlink isn't sending any resets) but LD2 doesn't toggle.

I used STStudio to look at the registers on my nucleo after the power cycle, and it looks like they reset, but the main while() was never reached. This is what makes me wonder weather the program was erased from flash. How would I use stutility to check the registers to see if the program was erased?

...the current code.

dlepe
Associate II

UPDATE: Solved the Issue

The problem wasn't hardware related. I had a few lines of code from a while back that initialized the DWT cycle counter.

Old Code:

DWT->CYCCNT = 0;

DWT-> CTRL |= 1;

New Code:

CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk;

DWT-> CYCCNT = 0;

DWT-> CTRL |= DWT_CTRL_CYCCNTENA_Msk;

I did a bit more research on how to use stutility and verified that the program was actually still in flash after a power cycle, per Clive's suggestion. Then began the hunt for the troublesome lines of code.