cancel
Showing results for 
Search instead for 
Did you mean: 

St-Link connects and programs STM32G4 but code never runs...is there faults state data saved?

KHarb.1
Senior

I have a board that programs without error but fails to run code most of the time. In the failing state, I can use CubeProgrammer and ST-link to view registers after programming and activate peripherals that would have been enabled by code. I can see these peripherals run as they should, and the software shows the CPU running, but again…no code executes.

After repeated plugging\unplugging\re-programming I can randomly see it in a state where it executes code as it should but its not common. I also see hardware reset commands randomly make run code as well, but also not common.

Are there registers I can read that will give me clues as to why code never runs or runs and hangs?

1 ACCEPTED SOLUTION

Accepted Solutions

Your Hard Fault Handler could output the salient processor and fault registers, and work from there.

Similarly if it ends up in the Error Handler, giving the file and line that originated from.

Check that BOOT0 is pulled LOW to ensure the FLASH code is executed out of startup.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

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

View solution in original post

2 REPLIES 2

Your Hard Fault Handler could output the salient processor and fault registers, and work from there.

Similarly if it ends up in the Error Handler, giving the file and line that originated from.

Check that BOOT0 is pulled LOW to ensure the FLASH code is executed out of startup.

https://github.com/cturvey/RandomNinjaChef/blob/main/KeilHardFault.c

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

The fault registers are what I wanted to know about. Where do I read?

Nevertheless I think I isolated it to a two factor failure:

1. Configuring the Boot0 pin as an output in Cube disables it's boot behavior.  If you have a minimal test setup that leaves the pin unconfigured, it regains the need to be held low for the intended boot process.  Disabling the peripheral that lands on that pin via Cube changes the BOOT registers so the pin activates for the boot process and screws your attempt at debugging.

2. If you have previous boards that behave fortunately, a floating boot0 pin still processes at logic low and boots the system normally if the pin isn't connected to it's target component yet...which lets the mistake persist through multiple revs.