Debugging firmware with a bootloader at the top of memory

[rsoc]

I am attempting to debug my firmware for a STM32L452xx chip, which is programmed in at the memory address 0x08010000. The bootloader will be placed at 0x08000000, but at the moment the memory is empty. Is it possible to trick the debugger so it always starts at main for the firmware in the debugger i.e. somewhere after 0x08010000 memory address? I changed the IROM1 address, as well as the FLASH_BASE address in the HAL so the vector table is configured correctly. I am just struggling with the debugger aspect of running to main on the entrance to the debugger. I "think" I need to set the MSP pointer when i enter the debugger to a specific memory address, but I am unsure. Also am unsure if I need to do something else.

I've already written a couple other bootloaders for different stm32 chips, but I've never gotten over the hump to be able to debug the firmware from a non-top memory address. I usually need to change the address settings before trying to debug. Hoping someone will tell me I am not doing something obvious?

Thanks!

[waclawek.jan]

> The bootloader will be placed at 0x08000000, but at the moment the memory is empty.

Why? It's simple to write a stub bootloader, which does nothing just jumps to the real application.

JW

[Pavel A.]

> Is it possible to trick the debugger so it always starts at main for the firmware in the debugger i.e. somewhere after 0x08010000 memory address?

Possible. You can override the start address and MSP in debugger script - but why if a stub bootloader as Jan advises, solves the problem.

Just remember to NOT erase whole flash when you debug, to keep the bootloader.

-- pa

[rsoc]

Even if with a stub bootloader that jumps to the 0x08010000 memory address, my experience is that trying to use the debugger with this setup does not run to main correctly. Is that not the expectation?

i guess im asking: should i be able to use my debugger with a bootloader and the appropriate jump to the firmware I am trying to debug? If thats true, with no project setting modifications (i use keil), I’ll throw one in and give it a go

[waclawek.jan]

> my experience is that trying to use the debugger with this setup does not run to main correctly

One day you would need to write the final bootloader anyway. How would you then expect it to run the main correctly?

Do what the processor does: reset all already modified registers (and by reset I don't mean clear, as ST confusingly do) i.e. nothing in the stub, set VTOR, read first word from the new vector table into the stack pointer and read the second into the program counter. Do it in asm if in doubt.

JW