How to setup debug with STM32N6 in FSBL Load and Run configuration?

csaji · ‎2026-04-22

How can I debug an STM32N6 project when using a load-and-run configuration? CubeMX generates two separate projects, and I’m able to debug each one individually when the BOOT1 pin is set high. However, it seems that if I only debug the application project, the FSBL never executes, so the system clocks aren’t initialized. What’s the correct approach to debugging both projects together?

I came across a debugging guide, but it only applies to the XIP configuration.

Amel NASRI · ‎2026-04-23

Hi @csaji ,

If you are using STM32CubeIDE, this article can be helpful for you: How to debug STM32N6 using STM32CubeIDE.

If you are getting started with STM32N6, several other articles are available on this link.

-Amel

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

csaji · ‎2026-04-23

Hi Amel,

Thanks for your reply. The article you linked is for the FSBL XiP configuration. Does the same setup apply for FSBL Load and Run configuration?

NT · ‎2026-05-16

Hi csaji,

Did you ever get a solution to this? I'm trying to do exactly the same. I've been through the relevant referenced articles and while there's some good stuff on building for load and run and how to debug XIP, I too want to debug through the FSBL and into the Appli in internal RAM but can't find any info on how to achieve it. Any pointers would be gratefully received.

csaji · ‎2026-05-17

I was able to follow the steps for the XiP debug and get it working for the FSBL. If you set software breakpoints before the application project is running, the program will not hit it. You need to set hardware breakpoints. Feel free to ask if you have any more questions.

NT · ‎2026-05-18

Hi csaji,

Thanks for the reply. I'm very new to this whole architecture and not hugely familiar with the tools, but I managed initially to download both FSBL and Appli projects directly to RAM and debug my FSBL code. However, taking this route, my Appli Vector Table was identified at the wrong address. I don't fully understand what I'm doing to be honest, but I found it at an offset from where JumpToApplication() finds it. My current HACK is to add (or subtract) the offset (depending on whether I target Secure or Nonsecure memory) and now I can download FSBL and Appli straght to RAM, set breakpoints in both and debug both in a single debug session. I know it's not the way it should be done, so I might post a detailed description in the hope that someone can set me on the right path.

csaji · ‎2026-05-18

What board are you using? Is it the discovery kit, nucleo, or a custom chip down design?

NT · ‎2026-05-19

Hi csaji,

I'm just using the Nucleo. I am starting to understand everything a bit more. I understand where my Hack offset came from. Basically it was a misunderstanding between the text and an image in the tutorial I've been following and changes to the Destination Address in CubeMX not actually taking effect (so I clearly don't fully understand the rules there). Now I've got rid of the offset, my current hack is to 'extern BOOTStatus_TypeDef JumpToApplication(void);' in my FSBL main() and when in DEBUG, call it instead of 'BOOT_Application()'. That allows me to download both FSBL and Appli to RAM in one go, set breakpoints in either or both and just run. It is a hack because 'JumpToApplication()' clearly isn't meant to be visible outside of 'stm32_boot_lrun.c' (It's not prototyped in the header, but neither is it declared static) and if ST changes the internals of that module it could easily break. I just don't know how I should be really doing this, but it works for me at the moment and at least I can move forward and keep learning.

Best Regards,

Nick