Skip to main content
M
makturan
Associate
July 20, 2026
Solved

STM32N6: Black screen after HAL_NVIC_SystemReset() — FSBL not booting, works fine after NRST/power cycle

  • July 20, 2026
  • 11 replies
  • 252 views

STM32N6: Black screen after HAL_NVIC_SystemReset() — FSBL not booting, works fine after NRST/power cycle

Gövde:

Hello,

I have a bootloader (FSBL) and a separate application on anSTM32N645L0, running from external XSPI NOR flash MX25UM25645GXDI00 in memory-mapped XIP mode (Octal DTR).

Setup:

  • FSBL configures the external flash into Octal DTR mode (volatile CR) at every boot and shows update/bootloader graphics on the display
  • The application runs its own graphics
  • To enter bootloader mode from the application, call HAL_NVIC_SystemReset()

Problem:
After HAL_NVIC_SystemReset(), the device stays on a black screen — the FSBL graphics never appear. However, if I reset via the NRST button or a full power cycle, everything boots normally.

What I suspect:
Since the N6 is flashless, BootROM must read the FSBL from external flash in standard SPI mode. My theory is that after a software reset the flash chip stays in Octal DTR mode (it doesn't lose power), so BootROM cannot read the FSBL at all.

Questions:

  1. Is the correct fix to send the flash software reset sequence (0x66/0x99 in the current protocol) and de-init the XSPI before calling HAL_NVIC_SystemReset()? Can you share an example function?
  2. Does BootROM on the N6 perform any flash reset itself, or does it strictly assume the flash is in its power-on state?

Toolchain: [STM32CubeIDE 1.19  / CubeMX ], HAL version [x.y], board: [custom / STM32N6570-DK]

Thanks!

Best answer by RomainR.

Hi @makturan 

At this stage, the most likely hypothesis is that the BootROM is unable to restart properly after the software reset. This could be related to:

  • An incompatible peripheral clock configuration.
  • An unexpected XSPI state.
  • An external memory device not responding as expected during the first boot transactions.
  • One of the "blocking failure" cases documented in UM3234.

The following actions are recommended at this stage.
1. Check the Blocking Failure causes
We recommend investigating the blocking failure causes as described in UM3234.
This verification will help determine whether the BootROM detects a specific failure condition during the boot phase.

2. Re-check the clock configurations mentioned in ES0620 section 2.2.22
Please confirm that the following registers are configured according to the errata recommendations:
RCC_CCIPR6, RCC_CCIPR7, RCC_CCIPR8 and RCC_CCIPR13

3. Perform oscilloscope measurements
To confirm whether the BootROM is actually attempting to access the external memory after the software reset, we recommend performing measurements on the interface between the STM32N6 XSPI peripheral and the MX25UM25645GXDI00.
The signals to monitor are : SLCK, D0, D1 and use CS as trigger.
Note : The BootROM configures XSPI1-P2 in single-line SPI mode (MOSI, MISO, SCK, and CS) at 64 MHz (refer to UM3234).

During the restart sequence following the NVIC_SystemReset(), the observed signals should be checked and compared against a reset sequence following a POR. In particular, please verify:

  • The presence of an approximately 64 MHz clock.
  • The presence of activity on the data lines.
  • Whether this activity is consistent or differs between a successful restart and a blocked restart.

After all these checks have been completed, it will be necessary to continue the investigation with a full review of the STM32N6 hardware design in order to verify the integrity of all power supplies as well as the state and behavior of the NRST pin.

Additionally, you may try the project that includes the Power-On Reset workaround. The signed binary available in the directory \bin can be programmed directly into the external Flash memory.
Best regards,

Romain,

11 replies

S
Saket_Om
ST Technical Moderator
July 20, 2026

Hello ​@makturan 

The issue may be related to the errata 2.2.18 or 2.2.22 described in ES0620 Rev4. 

Please try to apply the workarounds described in the errata sheet. 

Please refer to the post below also:

STM32N657-DK: BootROM hangs after reset if XSPI1 has been initialized (power cycle required) | Comm…

 

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
M
makturanAuthor
Associate
July 21, 2026

Hello,

 

I tried to apply the workarounds described in the errata sheet.

 

I added this function to my application code, but the result is the same. It continues to run using power cycling.

 

void reboot()

{

__disable_irq();

 

uint8_t retVal;

retVal = HAL_UART_DeInit(&huart4);

if (retVal != HAL_OK)

{

return;

}

 

RCC->CCIPR6 = 0;

RCC->CCIPR7 = 0x200;

RCC->CCIPR8 = 0;

RCC->CCIPR13 = 0;

 

/*

* Force completion of RCC writes before issuing the reset.

*

* Volatile readback prevents the compiler and bus fabric from leaving the

* final RCC write pending.

*/

(void)RCC->CCIPR6;

(void)RCC->CCIPR7;

(void)RCC->CCIPR8;

(void)RCC->CCIPR13;

 

__DSB();

__ISB();

 

/*

* Do not call application code, HAL functions, or external-flash-resident

* functions between the workaround and NVIC_SystemReset().

*/

NVIC_SystemReset();

 

/* NVIC_SystemReset() should never return. */

for (;;)

{

__NOP();

}

}

S
Saket_Om
ST Technical Moderator
July 21, 2026

Hello ​@makturan 

You should apply exactly the same code as in the thread below:

STM32N657-DK: BootROM hangs after reset if XSPI1 has been initialized (power cycle required) | Comm…

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
S
Saket_Om
ST Technical Moderator
July 21, 2026

Hello ​@makturan 

Could you please share your code ? The main.c of your FSBL code.  

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Saket_Om
M
makturanAuthor
Associate
July 22, 2026

Hi, 

 

#define NRST_MAGIC_ADDRESS (0x34001004UL)

#define NRST_MAGIC_VALUE (0x11223344UL)

 

static void Apply_NRST_Workaround(void)

{

volatile uint32_t * const magic = (volatile uint32_t *)NRST_MAGIC_ADDRESS;

__HAL_RCC_SYSCFG_CLK_ENABLE();

__DSB();

/* First pass */

if (*magic != NRST_MAGIC_VALUE)

{

*magic = NRST_MAGIC_VALUE;

__DSB();

SET_BIT(SYSCFG->CM55RSTCR, SYSCFG_CM55RSTCR_CORE_RESET_TYPE);

(void)SYSCFG->CM55RSTCR;

__DSB();

__ISB();

/* Software reset */

NVIC_SystemReset();

while (1) { __NOP(); }

}

/* Second pass */

SET_BIT(SYSCFG->CM55RSTCR, SYSCFG_CM55RSTCR_CORE_RESET_TYPE);

(void)SYSCFG->CM55RSTCR;

__DSB();

__ISB();

}

 

/* USER CODE END 0 */

 

/**

* @brief The application entry point.

* @retval int

*/

int main(void)

{

 

/* USER CODE BEGIN 1 */

//Enable NPU internal RAM (4x448KB)

LL_MEM_EnableClock(LL_MEM_AXISRAM3);

LL_MEM_EnableClock(LL_MEM_AXISRAM4);

LL_MEM_EnableClock(LL_MEM_AXISRAM5);

LL_MEM_EnableClock(LL_MEM_AXISRAM6);

 

RCC->MEMENR |= RCC_MEMENR_AXISRAM3EN | RCC_MEMENR_AXISRAM4EN | RCC_MEMENR_AXISRAM5EN | RCC_MEMENR_AXISRAM6EN;

*((uint32_t *) (RAMCFG_BASE_S + 0x080 + 0x80 * (3 - 2))) = 0x0; // AXISRAM3 memory is powered

*((uint32_t *) (RAMCFG_BASE_S + 0x080 + 0x80 * (4 - 2))) = 0x0; // AXISRAM4 memory is powered

*((uint32_t *) (RAMCFG_BASE_S + 0x080 + 0x80 * (5 - 2))) = 0x0; // AXISRAM5 memory is powered

*((uint32_t *) (RAMCFG_BASE_S + 0x080 + 0x80 * (6 - 2))) = 0x0; // AXISRAM6 memory is powered

 

/* This initializations are required for BKPSRAM init.

* Use this calls also in main application to r/w.

*/

__HAL_RCC_RAMCFG_CLK_ENABLE();

__HAL_RCC_PWR_CLK_ENABLE();

__HAL_RCC_BKPSRAM_MEM_CLK_ENABLE();

PWR_S->DBPCR = PWR_DBPCR_DBP;

PWR_S->BDCR2 |= PWR_BDCR2_BKPRBSEN;

/* Reset the RTC peripheral and the RTC clock source selection */

HAL_PWR_EnableBkUpAccess();

//__HAL_RCC_BACKUPRESET_FORCE();

//__HAL_RCC_BACKUPRESET_RELEASE();

/* USER CODE END 1 */

 

/* MPU Configuration--------------------------------------------------------*/

MPU_Config();

 

/* Enable the CPU Cache */

 

/* Enable I-Cache---------------------------------------------------------*/

SCB_EnableICache();

 

/* Enable D-Cache---------------------------------------------------------*/

SCB_EnableDCache();

 

/* MCU Configuration--------------------------------------------------------*/

 

Apply_NRST_Workaround();

HAL_Init();

 

/* USER CODE BEGIN Init */

 

/* USER CODE END Init */

 

/* Configure the system clock */

SystemClock_Config();

 

/* Configure the peripherals common clocks */

PeriphCommonClock_Config();

 

/* USER CODE BEGIN SysInit */

SystemIsolation_Config();

/* Set OTP fuses for XSPI IO pins speed optimization */

if(OTP_Config() != 0){

Error_Handler();

}

/* USER CODE END SysInit */

 

/* Initialize all configured peripherals */

MX_GPIO_Init();

MX_HPDMA1_Init();

MX_XSPI2_Init();

/* USER CODE BEGIN 2 */

MX_EXTMEM_MANAGER_Init();

 

//---------------------------------------------------------------------------------------------------------------------

 

void reboot()

{

RCC->CCIPR6 = 0;

NVIC_SystemReset();

}

 

RomainR.
RomainR.
ST Employee
July 22, 2026

Hello ​@makturan 

I understand that your are using a custom board with STM32N645L0 and MX25UM25645GXDI00 serial octal NOR flash.

  1. Could you confirm that the MX25UM25645GXDI00 RESET# pin is physically connected with the NRST pin of STM32N6 as explained in Figure 23. XSPI direct mode example of AN5967 ?
  2. Could you try to implement the same workaround reset code below as recommended in the ES0620:

/* USER CODE BEGIN PV */
volatile uint32_t * init_p = (volatile uint32_t *) 0x34001004;
/* USER CODE END PV */

/**
* @brief The application entry point.
* @retval int
*/
int main(void)
{
  /* USER CODE BEGIN 1 */
  /* Power-On reset workaround ES0620 2.2.18 */
  __HAL_RCC_SYSCFG_CLK_ENABLE();
  if(*init_p != 0x11223344)   
  {
    *init_p=0x11223344;              
    HAL_SYSCFG_EnablePowerOnReset(); 
	__ISB();                         
	__DSB();                         
	NVIC_SystemReset();              
  }
  /* USER CODE END 1 */

  /* Enable I-Cache */
  SCB_EnableICache();

  /* Enable D-Cache */
  SCB_EnableDCache();

  /* MCU Configuration */
  HAL_Init();

  /* USER CODE BEGIN Init */

  /* USER CODE END Init */

  /* Configure the system clock */
  SystemClock_Config();

  /* USER CODE BEGIN SysInit */
  /**> (1) Enable here AXISRAM3 to 6 */
  /**> (2) Enable here BACKUPSRAM    */
  /**> (3) Configure here MPU */

  /* USER CODE END SysInit */
  /* USER CODE BEGIN 2 */
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

Best regards,

Romain

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.
M
Mark21
Visitor
August 15, 2026

Hi.

Were you able to resolve the issue? It looks like I’m experiencing the same problem.

MCU: STM32N657L0H
Flash memory: MX66UW1G45

Sometimes, after NVIC_SystemReset() it looks like the BootROM does not start. The board draws less current than normally - exactly the same amount as when the MCU is in the reset state. The USB port is inactive.

Briefly pulling the NRST pin to GND causes the MCU to start correctly.

 

BR

Terms & ConditionsAccessibility statement