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

[silvia_b · Accepted solution]

Hi Romain

I managed to solve the problem! I went digging through the reference manual and found the RCC reset duration control register (RCC_RDCR). Setting the Minimum Reset Duration (MRD) bits makes the NRST pin reset work perfectly.

My sequence is now:

1. Call __HAL_RCC_SYSCFG_CLK_ENABLE()
2. Set the CORE_RESET_TYPE bit in the SYSCFG_CM55RSTCR register
3. Restore registers RCC_CCIPR6 through RCC_CCIPR13 to their defaults
4. Set the MRD bits in the RCC_RDCR register to 0x05 (haven't tried any other value at this point, a shorter duration might also work)
5. __DSB(); __ISB();
6. call NVIC_SystemReset()

Thank you very much for your guidance

Best regards,

Silvia

[RomainR.]

Hello @silvia_b 

Probably restoring the registers RCC_CCIPR6 through RCC_CCIPR13 to their default values is the key element.

That’s good news if you’ve fixed it.
Could you mark the answer as “Accept as Solution”?

Best regards,
Romain

[silvia_b]

Hello Romain,

To be clear, I had tried applying the workarounds from sections 2.2.19 and 2.2.23 before starting this thread. A colleague of mine had also tried the same with no success.

I'm sure the workarounds (plus your tip about __HAL_RCC_SYSCFG_CLK_ENABLE) are essential for resetting to work, but it wasn't until I added the write to the RCC_RDCR register that I saw any success

Best regards,

Silvia