FSBL + Application projects fail on STM32N6570-DK board

[Pfaa]

Hello everyone,

I am working with the STM32N6570-DK discovery kit and I have encountered a strange behavior that I cannot explain.

When I use the ST-provided example projects that include both an FSBL (First Stage Boot Loader) and an Application image — for example:

• Template_LRUN

• Template_FSBL_XIP

• JPEG_EncodingFromOSPI_DMA

they fail to run correctly on my STM32N6570-DK boards.
However, the exact same projects (same binaries, same flashing procedure) work perfectly on another identical STM32N6570-DK board (I was able to test the same projects on another STM32N6570-DK discovery kit provided by a friend).

Interestingly, simpler examples that only contain an FSBL project (for example GPIO_IOToggle) work fine on my board.

Before testing the ST-provided examples, I had tried to debug my own application on the same board.
During debugging, my code ended up in a HardFault error, and since then, it seems that any project which includes both an FSBL and an Application can no longer run properly on this board.

This makes me wonder whether something in the memory configuration might have been altered or locked after the crash — preventing the Application stage from being correctly loaded or executed.

I would like to understand what could cause this behavior and how to restore the board so that FSBL + Application projects can run again normally.

Any advice or diagnostic steps would be greatly appreciated.

Thank you in advance!

[STackPointer64]

Hello @Pfaa, and welcome to ST community!

Have you checked the BOOT0 and BOOT1 switches on your board? Since your board was able to run FSBL examples, it means developer mode is set with BOOT1 set to HIGH. Try setting both BOOT1 and BOOT0 to LOW to enable booting from FLASH.

Best regards,

[Pfaa]

Hello @STackPointer64, and thank you for your reply!

So I tried to debug it and followed this tutorial: How to debug STM32N6 using STM32CubeIDE - STMicroelectronics Community and as I said it doesn't work with my board but with the other one it did. There I have BOOT1 set to high. Now I tried booting from FLASH with both switches set to LOW. But it did not work. I also used the Template_FSBL_XIP.

Best regards,

[STackPointer64]

I see. Could you specify the error messages you see when trying to run the application? Also, during your latest successful debugging session, did you program any option bytes? To resolve this, try connecting to your board using STM32CubeProgrammer, select the OB tab from the left bar, click the arrow next to Read, and choose Reset MCU to factory settings.

[Pfaa]

So when I debug it and let it run, I jump to the HardFault_Handler(). The Fault Analyzer looks like this:

Unfortunately under the OB tab I can not find the option Reset MCU to factory settings. It looks like this:

And as far as I know, I didn't program any option bytes, at least I didn't do it on purpose.

[STackPointer64]

Could you export your OTP configuration and attach it to the thread?

1. Click on OTP in the menu on the left.
2. Click Export below, save the file as text, and attach it here.

Could you also answer the following questions?

• When you ran the same application on the other identical board, was it in the same STM32CubeIDE working environment?
• Have you made any changes to the debug/build configuration?
• Have you followed the instructions in the README file to sign the application binary?

[Pfaa]

I attached the OTP configuration to the thread.

To your questions:

• It was the same STM32CubeIDE working environment
• I have not made any changes to the debug/build configuration
• And I also followed the instructions in the README file to sign the application binary

[STackPointer64]

Hello @Pfaa,

Thank you for your patience. That is unusual. Could you please attach the project that failed to execute and caused the hard fault? I understand it is the example provided by ST, but I am interested in any changes made to the environment by STM32CubeIDE. Debugging crashes may leave the debugger in an inconsistent state or corrupt the CubeIDE workspace metadata. Meanwhile, I suggest downloading a fresh firmware project and running it in a new workspace in CubeIDE.

Best regards,

[Pfaa]

Hello @STackPointer64 ,

Sure, thank you for your efforts. I exported the whole folder with the project and attach it here. I hope that's what you meant. 

Also while following your suggestions, I noticed some strange behaviour I can not explain.

I removed the firmware version V1.2.0 and installed it new, and I also used a new workspace and tried to debug the project Template_FSBL_XIP and it did not work. When I started debbuging the first breakpoint is at BOOT_Application (like in the tutorial How to debug STM32N6 using STM32CubeIDE - STMicroelectronics Community). Then I wanted to run the code, clicked resume and lost the connection to the board. 

Then I used the firmware version V1.1.1 and also tried to debug the project Template_FSBL_XIP and this time it worked and the LED was blinking. 

I have no idea why this the case, maybe you have an idea...

Best regards,

[RomainR.]

Hello @Pfaa 

There are no Option bytes on the STM32N6, only OTPs (One-Time Programmable bits). And I have checked the list of OTPs you sent, and it seems correct to me.

I understand your issue is that on a single board, you cannot debug a project in DEV_BOOT (BOOT1=1) nor execute it in FlashBoot (from flash memory).

Can you confirm the following points:

1. In DEV_BOOT, after a reset, is LED2 (red) is on?

2. Has this failing board worked in the past? What is its origin?
3. Can you share both the version of your STM32N657-DK and the marking of the non-working STM32N6?

Please find below the images you need to check:

Best regards

Romain