STM32 going into system memory area when debugging starts

[alexxs]

Hi,

I'm running a fresh board on an STM32L431RCT6. I'm able to successfully run and debug a simple application that I created with STM Cube, but, when flashing our ported application (we have moved from Kinetis, due to the chip shortage), the stack frame looks like it jumped from 0xFFFF FFFE to 0x800 0008 to 0xFFFF FFF9 and then to 0x1FFF 3EEC. I've shorted PH3/BOOT0 pin to ground and checked the 0x800 0000 memory to make sure the first 8 bytes contain the top of the RAM and the address of the main function. They do.

As you can probably tell, I'm not very familiar with the STM32 architecture, coming from Kinetis.

Thank you!

[alexxs]

The memory, both when it works (please see message below) is identical between the start address of the flash memory and what it's mapped at 0x00000000 

[alexxs]

JW,

Here's how SYSCFG looks when it doesn't work.

[alexxs]

I fixed the debugger not being able to locate the source files. Somehow the binary was optimized for size, not debugging and no debug information was added by the compiler. So that's sorted.

I'm still puzzled by why it needs a chip and debugger reset in order to work.

[alexxs]

As a brief update, I also shorted BOOT0 pin to GND. Only with this done am I able to debug properly after resetting (as described above).

[waclawek.jan]

In debugger, place a breakpoint at target of reset vector (i.e. the startup routine) and single-step etc.

Also, show what's there, best as mixed disasm/source.

It's very unusual that the interrupt vector table is completely 0xFFs. Are you sure this is intended?

JW

[alexxs]

> It's very unusual that the interrupt vector table is completely 0xFFs. Are you sure this is intended?

The interrupt vector table is not all 0xFFs. It's a valid solution to only have the first two words of the boot area programmed, one with the address where to put the stack and the other with the address of the reset handler. My problem is that, no matter what breakpoints I put in the reset handler, it never hits it without resetting the debugger once.

Then, as the MCU is initialized, VTOR is pointed towards the beginning of RAM, where the running vector table is stored.

I've attached two screenshots. One shows the Fault Analyzer, the disassembly and the source code, while the other one shows the memory from where it boots. I've also tried putting a handler on NMI, but it still triggers the fault.

 

[Tesla DeLorean]

Are you sure the SYSCFG clock is enabled in the RCC, reading all zero

[alexxs]

I don't think there's any code instruction that gets run in this situation. It just immediately hard faults.

[waclawek.jan]

Hi @alexxs​ ,

were you able to solve this problem?

JW

[alexxs]

Hi JW,

Unfortunately no, working around it for now.