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!

[waclawek.jan]

The 'L431 has Pattern 6 bootloader (see AN2606) which means that after programming an empty FLASH, you may need to perform a power-on reset or reload the option bytes.

JW

[alexxs]

Thanks for the suggestion. Unfortunately that wasn't it.

[Tesla DeLorean]

Which NXP Kinetis part, the spectrum is relatively broad.

It should act like other CM4F devices

Check what memory is mapped at Zero when your code runs. Should be a SYSCFG mapping register.

Make sure you reconfigure SCB->VTOR to the base of your application, and that your application correctly builds for 0x08000000.

Disassemble the built image, perhaps with FROMELF or OBJCOPY, and apply understanding of Cortex-Mx parts generally, to walk the initial entry and progress from Reset_Handler.

[waclawek.jan]

> Unfortunately that wasn't it.

What wasn't what? Please elaborate.

JW

[alexxs]

Meant that it wasn't because of lacking the power-on reset. The boot source was one my first gotos, investigated both the BOOT0 pin state as well as the option bits.

[alexxs]

A variety of them: K21, 22, 24, 26 and 66.

I've looked at the SYSCFG register and it shows as booting from flash both for the simple test app (that works) and our ported application. The SCB->VTOR is my last go-to, that's probably the biggest difference. The simple app I'm testing with stores the interrupt vectors in flash, while ours does it in RAM.

[waclawek.jan]

> the stack frame looks like

Show.

> I've looked at the SYSCFG register

Which SYSCFG register? Show..

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

JW

[Tesla DeLorean]

Memory view at 0x00000000 might also be illustrative.

[alexxs]

So this is how the call stack looks along with the Fault Analyzer after the initial debugger run.  

However, if I press the "Reset the chip and restart debug session", it correctly goes to the 'main' routine. The problem there is that it doesn't seem to be able to load the source files and I can't debug. This is odd because:

1. The simple app can be debugged from the first start of the debugger (I don't need to reset the chip and restart the debug session in order for it to work)
2. Is able to correctly open its source files