Skip to main content
Graduate
December 14, 2023
Solved

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

  • December 14, 2023
  • 3 replies
  • 2424 views

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?

    This topic has been closed for replies.
    Best answer by DavidNaviaux

    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! 

    3 replies

    Super User
    December 14, 2023

    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).

     

    Graduate
    December 14, 2023

    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?

     

    Graduate II
    December 14, 2023

    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.

    Graduate
    December 14, 2023

    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?

     

    Super User
    December 14, 2023

    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.

     

    Graduate
    December 14, 2023

    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.