STM32N6 can't wake up from standby on WKUP pin.

[Mikk Leini]

I am struggling to wakeup STM32N6570-DK from standby mode with user button (WKUP3).

I created an isolated CMake + VSCode test project and share it in zip file. Based on latest CubeMX 6.17.0 and STM32N6 HAL 1.3.0. There is application and FSBL but I only use FSBL and do not jump into Application. My intention is that after wake-up, MCU launches Boot ROM that launches FSBL.

The core part of the code is:

static void EnterStandbyMode(void)
{
  PWREx_WakeupPinTypeDef sWKUPConfigs = {0};
  
  /* Prevent any disturbing interrupts */
  __disable_irq();

  /* Enable the Wake-up pin functionality */
  sWKUPConfigs.WakeUpPin   = PWR_WAKEUP_PIN3; /* PC13 (User button) */
  sWKUPConfigs.PinPolarity = PWR_PIN_POLARITY_HIGH;
  sWKUPConfigs.PinPull     = PWR_PIN_PULL_DOWN;

  HAL_PWREx_EnableWakeUpPin(&sWKUPConfigs);
  HAL_PWR_ClearWakeupFlag(PWR_WAKEUP_FLAG_ALL);

  /* AN5946 and errata say that BSEC should be enabled to go stand-by. */
  __HAL_RCC_BSEC_CLK_SLEEP_ENABLE();
  __HAL_RCC_BSEC_CLK_ENABLE();
  
  /* Set init vector to Boot ROM. */
  SYSCFG->INITSVTORCR  = BOOTROM_BASE_S;
  SYSCFG->INITNSVTORCR = BOOTROM_BASE_NS;

  /* Clear previous stand-by flag and go to stand-by */
  __HAL_PWR_CLEAR_FLAG(PWR_FLAG_SBF);
  HAL_PWR_EnterSTANDBYMode();

  /* Should not get here.
   * Turn on red LED (active low) to signal problem */
  HAL_GPIO_WritePin(LED2_GPIO_Port, LED2_Pin, GPIO_PIN_RESET);
  Error_Handler();
}

It blinks the LED as I programmed, goes into standby mode and I can observe PWR_ON signal going low and turning off external regulators. Unfortunately it does not wake up. There is a power consumption increase after the button press, but I have no idea where the MCU stucks because it's not starting up again. I tried setting INITSVTORCR to Boot ROM vector, not setting it and setting it to zero, but no use.

I have read the datasheet, reference manual, errata, app note AN5946, consulted AI, checked examples (standby with RTC wakeup) and read this post: STM32N6 low-power modes and Standby demo - STMicroelectronics Community

I tried changing optimization, placing code into ITCM (and enabled ITCM retention), disabling cache. This test code is without resource isolation (RIF/RISAF), but in the real code I have it enabled and it still doesn't work. OTP fuses are default - as they come with DK. Stand-by mode prevention isn't enabled. The post-build step signs the binary and I program it into external Flash so Boot ROM can launch it without debugger.

Running out of ideas.

There something else strange. After adding "read back" line behind INITSVTORCR writing, MCU does not go to standby, but it does not fall-through to Error_Handler either.

  /* Set init vector to Boot ROM. */
  SYSCFG->INITSVTORCR  = BOOTROM_BASE_S;
  (void)SYSCFG->INITSVTORCR;

Why I add this? Because I don't know what else to try and Application SystemInit contains such thing. Looking at assembly listing, it doesn't seem to do any harm, yet it breaks things.

[Gyessine]

Hello @Mikk Leini 
when you said you checked the firmware example did you run it or just compared its code with your code.
I tried the standby example (just standby, no RTC) which also wakeup the board from standby using blue button like you want and it worked fine.
can you try and run it and see if it works for you?
BR
Gyessine

[Mikk Leini]

Hi @Gyessine 

I looked at RTC wakeup example because first I thought I'll make wakeup with tamper button - the second blue button. I thought I'll check and try the example project with STM32CubeIDE, but it didn't compile and I didn't want to start dealing with another problem. As the tamper functionality is more complex than WKUP then I tried to get WKUP pin working first. I know that one has an example also that you pointed to. but it also doesn't compile out-of-the-box in STM32CubeIDE v2.1.0. And I believe I understand how that is made to work - FSBL copies application into FLEXRAM retention area and launches there. INITSVTORCR is set to the same address as VTOR which is FLEXRAM address. But that example application is small, yet our application is more than 80 KiB and we use application placed into FSBL area (AXISRAM2), because 511 KiB that Boot ROM can copy & run is enough and execution from AXISRAM is faster and energy efficient than from external memory. So when I read RM about exiting stand-by, it says:

An enabled WKUP pin or an RTC event during Standby mode causes the program execution to start as after a system reset (fetch from SYSCFG_INITSVTORCR)

Many things do system reset and re-run the Boot ROM. When I set SYSCFG_INITSVTORCR to its HW default value (0x1800 0000 by RM) which is also the value of BOOTROM_BASE_S, then I just don't understand why WKUP does not launch it.

The next thing I am going to try is to place small code into FLEXRAM retention area that will call MCU reset, but original questions still remains.

[Mikk Leini]

Compilation problem was my bad - I didn't checkout git submodules of the CubeN6 repo. Now I compiled it, signed FSBL and Application, flashed them and tried. It works fine and current consumption is also okay (same as in my code).

Then I changed INITSVTORCR value in application SystemInit function here:

SYSCFG->INITSVTORCR = BOOTROM_BASE_S; // Original: SCB->VTOR;

On USER1 button press MCU gets stuck like my code and the current consumption is similar to just holding down reset button. After reset button press, the application flashes LED rapidly, indicating that MCU has been in stand-by.

How do explain it?

[Mikk Leini]

I made a lightweight "application" in assembler with shortened ISR table and placed into FLEXRAM retention area (0x34000000) and it only makes SW reset at reset handler. From real application (which is in FSBL area) I set the INITSVTORCR to the start of that lightweight application ISR table. It didn't work out of the box. There was a lot of struggle with optimization flags and code order, but for couple of times I managed to make the button press to restart application through SW reset. And then next day it didn't work even after code reverts, power cycles, etc. I have a feeling there is something off with Boot ROM. And there is indeed a record about that in errata:

2.2.23 Boot ROM execution failure after system reset due to wrong clocking of peripherals

I went through those clocks and made everything as required by Boot ROM to avoid clock source switching on runtime (that has some errata issue also). Even changed RTC from LSE to LSI although that would create a problem with inaccuracy. Still no help.

Then I tried stop mode. Did the same thing - SW reset after wakeup. If clocks are like errata mentions, then it restarts, otherwise it clearly stuck somewhere in Boot ROM because I observed exit from stop. But stop mode consumes more power so it's not ideal...

This is so bizarre and taking way too much time to get working. I wish ST people try to alter the example code like I wrote in my previous post and get it working. Maybe that reveals something.

Btw, the strange thing I reported about writing INITSVTORCR and reading back: I didn't check what's around those lines in SystemInit. SYSCFG is enabled before writing this register and disabled afterwards. Trying to write this register with SYSCFG disabled doesn't end well. And the read back on this line probably avoids wrong execution order due to Cortex M7 out-of-order execution feature.