Downloaded STM32H7A3 program runs but doesn't stay flashed

[magene]

I'm bringing up a new board using a STM32H7A3. I've developed, downloaded, debugged and run lots of test programs from the VisualGDB IDE.  Now I'm working on the main application. I can still develop, download, debug and run from VisualGDB but when I exit VisualGDB, power down the board and repower it, the program doesn't seem to start up.  Almost the very first thing the main app does is blink a LED and that's not happening after powering down and powering back up. VisualGDB has a simple HAL based Blinky example built in and as a test, I built this example and it works fine both from VGDB and after powering down and back up.

If I set a break point at the first line of code in my main app and look at the disassembled code, it starts running at memory location 0x08020DF8.  The Blinky app starts at 0X08000348.  Both of those memory locations are in the Flash memory space according to the reference manual so I'm pretty sure both programs are running from Flash memory.

I'm using a STLinkV3-PWR debugger for both programs.

Another hint is I can download the Blinky program .bin fileusing CubeProgrammer and it runs fine after power down/up.  But If I try to download my main app .bin file with CubeProgrammer, it doesn't run at all.

Seems like I need to set some bit somewhere before the download process to make sure the main app gets permanently programmed.  Or maybe there's a bit I have to set so the Flash doesn't get cleared on power up.  I've scoured the reference manual but haven't found anything helpful yet.

Any help will be greatly appreciated as always. - Thanks

[FBL]

Hello @magene 

Do you mean the target doesn't start running the code after programming unless it's power cycled. If so, since STM32 was previously connected to a debugger like ST-Link, even if it's not physically connected now, the STM32 might still detect a debugger as if it is connected, which could cause the issue. Therefore, a power-on reset might be necessary after programming. If the issue persists, Would you please share your st link firmware and IDE version?

[TDK]

Flash doesn't spontaneously erase itself, there's no flag or mechanism for that. Are you sure the program is actually gone? Connect with STM32CubeProgrammer and verify that the program is gone.

[magene]

I did what @TDK  suggested and connected with STM32Cube Programmer and I'm pretty sure the results are what he predicted: the Flash did not spontaneously erase itself.  Here's what I did.

Test 1: Run the program out of the VisualGDB IDE using a STLinkV3-PWR debugger.  The LED on my board blinks as expected, the program runs and prints out various messages to the console.  Stop the program at a reasonable breakpoint which disconnects VGDB from my board. Connect STM32Cube Programmer to my board and check a few memory locations above 0x08000000. 

Test 2: Hit the disconnect button in STM32Cube Programmer but leave the debugger connected.  Shut off the power using STM32CubeMonitor-Power. Wait 10 seconds.  Power up my board.  Reconnect Programmer and check the same memory locations.  Push the reset button and the LED doesn't blink.  Power down and power back up and the LED doesn't blink.

Test 3: Power down, physically disconnect the debugger from my board and power back up.  No LED blinks.

Results: The same value is in all the memory locations I checked manually before power down and after power up.

I think that means what @FBL suggested is also correct: the STM32H7A3 has the program in flash but thinks the debugger is still connected and is waiting for some command from the debugger to start running the program in flash.

I'm using a STLinkV3-Pwr for my debugger. In the upper right corner of the STM32CubeMonitor-Power - v1.2.1 window it ways the "Board firmware version VPWR V4.J2.B1.P4".

I'm using VisualGDB version 5.6R9 (build 4777) for my IDE.  The debug settings are Debug using: OpenOCD and JTAG/SWD programmer: ST-Link v3.

WRT to the question "Do you mean the target doesn't start running the code after programming unless it's power cycled".  The answer is no.  The target runs the code just fine from the IDE.  I can power cycle and as long as I download and run the code from the IDE it works fine. The program will not run after the program is stopped in the IDE and the target is power cycled. Subsequent power cycling and/or hitting the reset button does not start the program.

Is there something I can do to make sure the target is not waiting for a debugger to do something when no debugger is connected?

Thanks

[TDK]

> Is there something I can do to make sure the target is not waiting for a debugger to do something when no debugger is connected?

After a power cycle, the cpu is running code either in FLASH or RAM according to various BOOT pin states and option bytes (see AN2606 for details). There is no flag to say "wait until a debugger is present before running."

What could be happening is your BOOT pins or option bytes are causing the cpu to jump to the system bootloader, or some other code which isn't what you're expecting. In STM32CubeIDE you can debug a chip without resetting it to see what code it's running. Your IDE may have something similar. Typically the user code in FLASH at 0x08000000 is run.

Is this a custom board? Is BOOT0 grounded?

When you debug code, the debugger explicitly sets the starting address, so it will start at the correct location regardless of BOOT pin and option byte settings.

[magene]

@TDK OK, that helps a lot.  This is a custom board.  I have a jumper on BOOT0 so I can pull it high or low but it is currently grounded through a 10K resistor. By option bytes, I'm assuming you mean the Flash registers, right?

I'm going through the Flash registers bit by bit to see if I can find anything that looks wrong or even questionable.  There area lot of registers and a lot of bits, so it will take me a while.  In addition, I have a whole bunch of test programs that work on a Nucleo-H7A3ZI-Q board and will start properly after power cycling so I can compare the Flash registers on the Nucleo with my custom board registers.

As always, thanks a tonne for your quick and informative replies. 

[TDK]

I mean option bytes. They are flash registers but so are a lot of other things. Connect with STM32CubeProgrammer and click the OB icon. There are only a few relevant ones.

[magene]

One more hint.  I modified a simple blinky program that used the HAL drivers and worked on the Nucleo H7A3ZI-Q from my IDE, after pushing the reset button and after power cycling so it worked on my new custom board.  And good news, it worked from the IDE, after reset and after power cycling.  One big difference is the simple blinky program runs from the internal HSI and the System Clock is set up by HAL_Init().  My main app runs from the external HSE and LSE and the System Clock is set up by the CubeMX generated SystemClock_Config() function.  I'm particularly suspicious of the 3 endless loops in the CubeMX code that check if the LSE, PLL1 and the SysClkSource are ready.  I'm not sure why it would run out of the IDE but not after reset or power cycling but I'm looking into it.

/* Wait till LSE is ready */
while (LL_RCC_LSE_IsReady() != 1)
{}

__STATIC_INLINE uint32_t LL_RCC_LSE_IsReady(void)
{
  return ((READ_BIT(RCC->BDCR, RCC_BDCR_LSERDY) == (RCC_BDCR_LSERDY)) ? 1UL : 0UL);
}

while (LL_RCC_PLL1_IsReady() != 1)
{}
__STATIC_INLINE uint32_t LL_RCC_PLL1_IsReady(void)
{
  return ((READ_BIT(RCC->CR, RCC_CR_PLL1RDY) == (RCC_CR_PLL1RDY)) ? 1UL : 0UL);
}

while (LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL1)
{}

__STATIC_INLINE uint32_t LL_RCC_GetSysClkSource(void)
{
  return (uint32_t)(READ_BIT(RCC->CFGR, RCC_CFGR_SWS));
}

And per  @TDK I checked the Option bytes in CubeProgrammer and nothing looked wrong to me.  Here's what I think it the most pertinent part.  If there's something else I should be checking, please let me know.

And I compared all the option bytes for my main app running on my custom board and the option bytes for the blinky program running on the Nucleo board and they were identical.

@TDK I don't seem to be able to send you a PM.  If you're willing, can you send me a PM?  thanks

[TDK · Accepted solution]

Okay, getting somewhere. Option bytes seem okay.

I would suggest seeing where the code is when it's frozen after a power reset. Probably it is waiting for LSE to come up (or HSE but more likely LSE). To do so:

• In debug configuration, Startup -> Load Image and Symbols -> Download -> False
• In debug configuration, Debugger -> Reset Behavior -> None

Keep your debugger connected, power cycle your board. It should "hang" as you describe. Now launch the debug configuration and hit pause. It will show where the program execution is currently at.

If those are the problem perhaps recheck your design for valid crystals and load caps. Try lower/higher cap values and/or higher drive settings.

https://www.st.com/resource/en/application_note/an2867-oscillator-design-guide-for-stm8afals-stm32-mcus-and-mpus-stmicroelectronics.pdf

[magene]

Thanks for the suggestion about finding the freeze point.  I used  the app note your referred to when designing the board and also looked at what ST does on their Nucleo, Disco and Eval boards.  I've got re-looking at the crystal/capacitor selection on my list of things to do.  My very long list of things to do.

Thanks as always.