Skip to main content
Visitor II
June 17, 2024
Solved

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

  • June 17, 2024
  • 1 reply
  • 897 views

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?

    This topic has been closed for replies.
    Best answer by Tesla DeLorean

    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

    1 reply

    Graduate II
    June 17, 2024

    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

    KHarb.1Author
    Visitor II
    June 18, 2024

    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.