Fimrware works when "run" or "debugged" but not after a power cycle

[DavidNaviaux]

I have spent all day on this.  Everything looks good because I can run or debug the firmware from within STM32CubeIDE and it works as would be expected.  However, after power cycling, the code is not running.

I have checked that my interrupt vector table is in the correct position.

Any suggestions?

[Pavel A.]

Is the vector table of your firmware not at the default address (0x08000000) ? Boot address altered by the option bytes? The debugger knows how to start your program anyway, but not the bare chip (and even not the CubeIDE debugger, after a chip reset).

[Tesla DeLorean]

Check BOOT0 is pulled low.

Instrument via serial port so debugger connectivity not required. Config GPIO and toggle in Reset Hander, be see if code alive. Add output to Hard Fault Handler, and Error Handler to see if they end up there for whatever reason.

[DavidNaviaux]

I double checked and my vector table is located ad 0x800_0000 as indicated by the VTOR register.

I currently have the options set to ignore the BOOT0 pin and always boot to flash.

I did not see a way to set a different flash boot address.  Is there a way to force the reset to a flash location other than 0x800_0000?

[Pavel A.]

> as indicated by the VTOR register

Nope. VTOR won't help, it's too late. Before VTOR is set by your program, something must find your start address and start your program))

> Is there a way to force the reset to a flash location other than 0x800_0000?

I don't have a G4 board, from documentation it only can select between Main flash, RAM and the system bootloader. So there should be your own bootloader, even a minimal one, just to jump to your firmware.

[DavidNaviaux]

The MCU BOOT0 pin is pulled low with a 10k resistor, and I have the options set to ignore the BOOT0 pin.  I have the NRST pin floating (only connected to the programming connector).  

I'm still a newbie with this MCU architecture and the STM32CubeIDE.  Is it difficult to add output to those handlers?

[DavidNaviaux]

How does the MCU know where the code is located, or does it always start executing from the alias 0x00000000 address?

If so, how can I get my code mapped to 0x0000_0000 without executing any code.  Are there some option bits that set that?

I know that the SYSCFG register has a bit to remap but, I thought that that register was not retained when power is off.

[DavidNaviaux · Accepted solution]

Pavel,

It turns out that my problem was that a "hard fault" was occurring at reset because I was accessing 32-bit data that was not aligned.

After adding the appropriate attributes to the structure typedefs as shown below, and with a little cleanup, my reset issues went away.

typedef struct __attribute__((packed,aligned(4)))
{
} MYSTRUCT;

I realize that normally, packing a structure is not required.  But the last two bytes of each structure that I keep a copy of in flash contains a CRC that I use to verify that the data is valid or not and I use the same functions to update that and to check it for all structures.  My functions that do that require the very last two bytes of the structures to contain the CRC.

I want to be able to debug my application code without the bootloader in place, so when doing that, it appears that I will need to add the stack pointer and the jump to my start code at 0x8000000, as you pointed out. 

Thank you! 

[DavidNaviaux]

Tesla, I found my problem.  It was due to hard faults that were occurring because I was accessing 32-bit data that was not properly aligned.  Once I fixed that, the reset problem went away.  

It turns out that much of the problems that I have been having were related to alignment issues.  My last few projects used 8-bit MCUs that alignment was not an issue and I made use of quite a bit of that code for this project.  It was a very hard lesson to learn!

Thank you for you help!