STM32G0 crashes into system memory bootloader everytime during debug

[TSu.1]

The codebase is generated by CubeMX and now I'm facing issues during debug.

debug method is SWD using ST-LINK V2.

In debug mode, after resume fron HAL_Init(); , the code will crashed into system memory zone and have no debug information.

Break at address "0x1fff12ca" with no debug information available, or outside of program code.

the location of the address varies around 0x1fffxxxx sometimes.

to be exact, the crash will happen when:

Initialize the IWDG

Using Flash R/W Operation

Start Timer (But not Init)

In STM32G031, 0x1fff12ca is located at system memory area where it houses the factory bootloader.

What confuses me is, I have another code project that has basically the same start up code at main() but it works just fine (in another STM32G031, and hardware connection is the same regarding BOOT0 pin). Tried Clean project and rebuild, restart IDE and change optimization, changing minimum heap and stack, absolutely no help whatsoever. I have not try to load the codes to another STM32G031 yet but what will be the possible reason that causes this?

[TDK]

Is this a custom board? If so, is BOOT0 held low? That is the most likely issue.

Is SCB->VTOR set up correctly? Generally should be pointing at 0x08000000.

IWDG in general does not stop during debug and may be resetting. Bootloader may be getting loaded if option bytes or BOOTx pins are not set correctly.

[TSu.1]

Yes both are custom board and the BOOT0 pin is technically 'floating' when SWCLK is not connected. No external pull-down resistor. 

usually for a brand new chip it should be fine without further setting ob and BOOTx pins, at least I have not encountered this for the last few other STM32G031s.

how do I check SCB-VTOR in STM32CubeIDE?

[TDK]

BOOT0 needs held low during startup to boot into user flash.

Alternatively, you can modify option bytes such that it ignored the BOOT0 pin and always boots there.

> usually for a brand new chip it should be fine without further setting ob and BOOTx pins

This is not correct. A floating BOOTx pin is a common cause of issues. There isn't a chip I know of where the value is ignored by default when the flash is not empty.

Edit: You might be correct here for the STM32G0x1 in particular. Seems like BOOTx pin value is not used by default. In which case I'd check option bytes to see how it's set up to boot.

[TSu.1]

---

@TDK wrote:

BOOT0 needs held low during startup to boot into user flash.

---

Shouldn't it was held low when the SWD is connected?

[TDK]

SWD is always active regardless of where the chip boots, bootloader or user code.

Did that fix the issue? The RM suggests the BOOTx pin is ignored as mentioned in the edit to my last post.

[TSu.1]

just checked the ob.

This is weird, per the ob settings this should boot from flash instead of system memory.

nBOOT_SEL: checked

nBOOT1: checked

nBOOT0: checked

[TDK]

The empty flash check is performed on power-up, not reset, so the chip will need to be power cycled after it is flashed.

In other words, if you load firmware on a fresh chip, then launch the firmware, any reset will cause the bootloader to load until a power cycle or OBL launch.

[TSu.1]

I guess this empty flash check will perform only once on the very first time programming? After the power cycle, if I load a new firmware it won't empty check anymore, right?

[TDK]

Correct. It checks at power on. If firmware is loaded, the flash will not be detected as empty.