STM32N6 - Unable to reset using NRST pin

[silvia_b]

Hi,

I am working with a custom board using an STM32N657X0H3Q and cannot for the life of me bring about a reset via the NRST pin.

I have tried applying the workarounds from errata sheet ES0620 - Rev 3, sections 2.2.19 and 2.2.23, but my device still just hangs when any reset is attempted and needs a power cycle to recover. 

In our setup:

• MCUboot and the application are both built as secure firmware
• the application runs from AXISRAM1 after RAM-load

Since it runs from AXISRAM1 which is where the errata recommends to place the First power-on reset flag, I instead decided to set the CORE_RESET_TYPE bit in the SYSCFG_CM55RSTCR register before each reset (in addition to resetting the clock switch control bitfields to their defaults). 

Does this type of setup have any implications regarding using the SYSRESETREQ bit to generate a software reset? 

Thank you

/ Silvia

[RomainR.]

Hello @silvia_b 

If you apply workaround 2.2.19 from ES0620 Rev. 3 and if yout want to change the CORE_RESET_TYPE bit in the SYSCFG_CM55RSTCR register, you must enable the SYSCFG clock. This is mandatory for the proposed workaround.
Bit 0 – SYSCFGEN: SYSCFG enable bit in the RCC_APB4HENR register first.

/* Enable SYSCFG Clock */
__HAL_RCC_SYSCFG_CLK_ENABLE()

Then apply the workaround.

if (*init_p != 0x11223344) // First power-on reset is detected
{
  *init_p = 0x11223344;   // Change init_p variable to a known value
  SYSCFG->CM55RSTCR |= 1; // Set power-on reset from NRST pin
  __ISB();                // Instruction Synchronization Barrier
  __DSB();                // Data Synchronization Barrier
  NVIC_SystemReset();     // Generate a system reset
}

Note: This will added in the next ES0620 revision.
Best regards,

Romain,

[silvia_b]

Hello Romain,

Thank you for that info :)

Sadly, adding that call does not seem to help in my case. My device still just hangs.

Could my issue have something to do with this note from workaround 2.2.23?:

"To successfully switch from one clock signal to another, ensure that both clock signals are present at their clock
switch inputs before updating the control bitfield value to reflect the new clock switch state."

I wasn't quite sure how exactly to ensure this

/ Silvia

[RomainR.]

Hello @silvia_b 

The issue you are encountering is due to attempts by the CPU to access peripherals or memory regions that are not valid or whose clocks are not enabled. This can include AXI SRAM, external memories connected through XSPI, RAM used by the D‑cache or I‑cache, as well any peripherals located on the AHB or APB buses.

When such an access occurs, the bus can end up waiting indefinitely, the CPU is no longer able to raise an exception, and the core becomes completely frozen.

But normally, the code that acts on CORE_RESET_TYPE should nevertheless resolve your issue.

If the reset cannot recover the STM32N6 in DEV_BOOT mode, it means the BootROM cannot restart properly. 
A link with errata 2.2.23 is indeed possible, since a reset causes the internal BootROM to restart.
And it would therefore be necessary to analyze your code in more detail and specifically check whether it modifies the contents of the registers RCC_CCIPR6 through RCC_CCIPR13.

I understand that this is a custom hardware design. If you are not able to resolve the issue, it will be also important to perform a review of your design, particularly regarding the power supplies, but also to verify whether the reset signals of the external Flash and RAM memories are correctly connected to the STM32N6 reset pin.
You can refer to the schematic of the STM32N657‑DK.
st.com/resource/en/schematic_pack/mb1939-n6570-c02-schematic.pdf

Best regards,
romain