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.

[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]

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

[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]

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]

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

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

 

[waclawek.jan]

Hi @alexxs​ ,

were you able to solve this problem?

JW

[alexxs]

Hi JW,

Unfortunately no, working around it for now.

[DPrie.1]

Hello Alexxs, 

Maybe the answer is late, but something similar happened to me, and maybe this could help someone.

I am using a custom bootloader, and when debugging the application (in 0x8005000, with the vector table displaced) I couldn't restart in debug mode, and I had to go out of the session and debug again.

In my case, I needed to declare the same peripherals (I2C and UARTS) in the bootloader and in the app, that's all!