2026-03-26 7:09 AM
We are currently working with a custom PCB using an STM32N6 chip and an MX25UM512G flash chip. The flash is connected identically to the Nucleo development board.
When powering up the board in Dev Boot mode, it is not possible to read the flash chip using CubeProgrammer. The MCU crashes, which we assume based on the reduced power consumption observed afterward.
If we first load a firmware image into SRAM using CubeIDE (which successfully connects to and reads the flash memory), then reading and writing the flash via CubeProgrammer works as expected.
However, after a power cycle without reloading the firmware into SRAM, the flash becomes inaccessible again.
Additionally, after flashing the firmware using this workaround (i.e., initializing the flash via our own firmware and then booting in Flash mode), the software is not executed from flash and the system does not boot.
Our assumption is that the flash is not correctly initialized by the boot ROM. Any help or suggestions would be highly appreciated.
Solved! Go to Solution.
2026-04-10 3:58 AM
Hello,
after our own Investigations we were able to pin Point and fix the Issue. The connection between PN7 and the reset lead to issues with booting from flash in Flash boot. Removing the connectiong resistor Solved the issue.
The Upload to the flash in dev Boot still doesn't work, but we are not able to do the required Hardware modification to figure out the Issue, but we have a software workaround. For sake of documentation the Workaround consinsts of 2 steps. First using the STMCubeIDE to upload and run a basic firmware image into Ram which initialises the Flash and then the Programmer schould work as expected.
Regards Nico
2026-03-26 8:27 AM
Hello @Nixxen ;
Could you please check the memory RESET pin.
It is recommended to connect the STM32 NRST pin with a reverse diode to each of all external RESET pins of external memories, to generate a proper hardware reset simultaneously as mentioned in Getting started with hardware development for STM32N6 MCUs - Application note.
Thank you.
Kaouthar
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.
2026-03-26 11:56 AM
I did not intend to accept this as a solution. We did initialy connect the flash reset to the OCTO-SPI Reset but also added a Line to the Hardwarereset of the SMT32. might there be an issue with the reset both being connected to the OCTO-SPI Reset and the external reset
Nico
2026-03-26 12:02 PM
@Nixxen wrote:
I did not intend to accept this as a solution.
How to unmark the solution:
2026-03-27 1:13 AM
Hello @Nixxen;
If you have a reset connection issue, external memory supplies (VDD_MEM1 and VDD_MEM2) must be cut for more than 1 ms to allow reboot on reset. For that I advise you to respect the recommendation.
Could you please share your schematic?
Thank you.
Kaouthar
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.
2026-03-27 4:41 AM
2026-04-09 9:29 AM
Hello @Nixxen ;
After checking your schematic, your aren't used a reversed diode to each of all external RESET pins of external memories as recommended in Getting started with hardware development for STM32N6 MCUs - Application note.
I recommend you to correct this issue by adding a reversed diode. Please let me know if the issue is solved or not?
I advise you to refer to Nucleo-N657X0-Q schematic and check your schematic.
Thank you.
Kaouthar
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.
2026-04-10 3:58 AM
Hello,
after our own Investigations we were able to pin Point and fix the Issue. The connection between PN7 and the reset lead to issues with booting from flash in Flash boot. Removing the connectiong resistor Solved the issue.
The Upload to the flash in dev Boot still doesn't work, but we are not able to do the required Hardware modification to figure out the Issue, but we have a software workaround. For sake of documentation the Workaround consinsts of 2 steps. First using the STMCubeIDE to upload and run a basic firmware image into Ram which initialises the Flash and then the Programmer schould work as expected.
Regards Nico