Flash erase fails on STM32N6 Nucleo board once FSBL executes HAL XSPI initialization

[edwind]

Dear,

When running the FSBL that includes HAL XSPI initialization logic on the Nucleo-N657X0-Q board (MB1940-N657X0Q-C02), the flash erase with the STM32CubeProgrammmer v2.22 sometimes fails. However, if I leave out the XSPI initialization logic for accessing the NOR flash, flash erase always succeeds. BOOT pin 1 is set to DEV and I am loading the FSBL firmware directly into RAM.

Do you have any idea why XSPI Init causes the flash erase to fail ?

BR,

EdwinD

 

[KDJEM.1]

Hello @edwind and welcome to the community;

 

Could you please share a screenshot of the error and the .log file.

Which XSPI clock are you using?

 

Thank you.

Kaouthar

[edwind]

Hi @KDJEM.1 

We are using XSPI with following clock config:

    PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_XSPI2;

    PeriphClkInitStruct.Xspi2ClockSelection = RCC_XSPI2CLKSOURCE_IC3;

    PeriphClkInitStruct.ICSelection[RCC_IC3].ClockSelection = RCC_ICCLKSOURCE_PLL1;

    PeriphClkInitStruct.ICSelection[RCC_IC3].ClockDivider = 24;

Please find attached requested logging and screenshot.

BR,

Edwin

 

 

 

 

[KDJEM.1]

Hello @edwind ,

 

Thank you for sharing the error issue and the log file.

Could you please check the dummy.

Thank you.

 

Kaouthar

[edwind]

Dear @KDJEM.1 

Can you please clarify what should be checked?

BR,

Edwin

 

 

[KDJEM.1]

Hello @edwind ;

 

You need to check the XSPI2 configuration. May be this STM32CubeN6/Projects/NUCLEO-N657X0-Q/Examples/XSPI/XSPI_NOR_MemoryMapped_DTR at main · STMicroelectronics/STM32CubeN6 · GitHub example help you for verification.

Please try to disable the I/O compensation cell (EN = 0, CS = 1) on the relevant power domains (VDD, VDDIO2, VDDIO3,VDDIO4, and VDDIO5) and use fixed compensation values for the RAPSRC[3:0] and RANSRC[3:0] bitfields as mentioned in the errata sheet.

 

Thank you.
Kaouthar

[edwind]

Hi @KDJEM.1 

I have tested with the XSPI_NOR_MemoryMapped_DTR project found in ST's repo at  location: STM32CubeN6\Projects\NUCLEO-N657X0-Q\Examples\XSPI. This example was compiled by STM32CubeIDE v2.1.0 loaded into RAM by the embedded ST-Link on the Nucleo, executed and after some time stopped. After this, I used STM32CubeProgrammer v2.22.0 to program something into flash memory, after I connect to it using the Hardware Reset option when connecting. When trying to program emb-platform-nxg-e6-fsbl-trusted.bin (another binary), STM32CubeProgrammer would halt and report the following in its log file:

 

11:25:44 : UR connection mode is defined with the HWrst reset mode
11:25:46 : ST-LINK SN : 002500283234511233353533
11:25:46 : ST-LINK FW : V3J17M10
11:25:46 : Board : NUCLEO-N657X0-Q
11:25:46 : Voltage : 3.25V
11:25:46 : SWD freq : 8000 KHz
11:25:46 : Connect mode: Normal
11:25:46 : Reset mode : Hardware reset
11:25:46 : Device ID : 0x486
11:25:46 : Revision ID : Rev Z
11:25:46 : Revision ID : Rev Z
11:25:46 : UPLOADING ...
11:25:46 : Size : 1024 Bytes
11:25:46 : Address : 0x8000000
11:25:46 : Read progress:
11:25:46 : Data read successfully
11:25:46 : Time elapsed during the read operation is: 00:00:00.002
11:25:54 : Opening and parsing file: emb-platform-nxg-e6-fsbl-trusted.bin
11:25:54 : Memory Programming ...
11:25:54 : File : emb-platform-nxg-e6-fsbl-trusted.bin
11:25:54 : Size : 92.34 KB 
11:25:54 : Address : 0x70000000
11:25:54 : Erasing memory corresponding to segment 0:
11:25:54 : Download in Progress:
11:25:54 : Error: failed to download Sector[0]
11:25:54 : Error: failed to download the File
11:25:54 : Warning: Connection to device 0x486 is lost
11:26:06 : Disconnected from device.

I made certain the hardware reset was performed by both the ST link as the Segger j-link. I even measured with an oscilloscope to verify that the reset was driven. No change in observable behavior was noticed, the device's flash was not approachable through the either Segger's JFlash and STM32CubeProgrammer.

Best regards,

Edwin

PS. ST's example does not use the compensation cells.

[KDJEM.1]

Hello @edwind ;

 

Could you please try with another binary file like as blink led binary.

Do you get the same issue?

 

Thank you.

Kaouthar

 

[Mikk Leini]

It could happen that you configure the NOR Flash with FSBL into non-default mode (change SOPI/DOPI, dummy cycles, etc.) and STM32CubeProgrammer connection isn't making hardware reset to MCU, so the Flash which uses same MCU NRST signal, doesn't get reset to default mode and CubeProgrammer external Flash loader just can't talk to it. Check your debug connection mode and reset modes, try out hardware reset.

[edwind]

Hi @Mikk Leini 

A hardware reset (verified the reset line on the scope) didn't solve the problem.

Best regards,

Edwin

 

 

[Mikk Leini]

I have NUCLEO-N657X0-Q that I haven't used yet and when I read out its HWCONF1 (OTP124) I see that HSLV_VDDIO3 is 0, which means XSPI2 isn't configured for less than 2.5V operation mode. But NOR Flash is at 1.8V based on schematic, so I suppose this bit must be set. Otherwise Flash is used with overvoltage...?!?

It reminds me this article: How to program the OTP fuse bits in the STM32N6 - STMicroelectronics Community

It appears N6 DK's have XSPI1 and XSPI2 low voltage bits set in factory and Nucleo's don't have. Note that Nucleo's do not have PSRAM, so only XSPI2 needs to be set.