STM32N6: Retain RAM contents across resets for OTA firmware updates

asdfasdf · ‎2025-05-31

Dear all,

I'm implementing Over-the-air firmware updates for a board using the STM32N657 MCU.

In the Appli, I download the new firmware binary over Wifi and store it to RAM at a fixed location in AXISRAM5 and 6. In order to flash the new binary to the OctoSPI Flash I prepend a "magic" header to the new firmware binary (still in RAM) and then restart the MCU using `HAL_NVIC_SystemReset`. Then, after this reset the FSBL checks the fixed location in RAM for the "magic" header. If present, it should flash the OctoSPI Flash with the new firmware binary using the ExtMem Manager (I cannot just flash directly from Appli because I use XIP and hence the Appli is running from OctoSPI in memory-mapped mode, preventing writes). I've done similar things with other MCUs and it worked perfectly fine.

However, it looks like on the STM32N6, the contents of AXISRAM5 and 6 are not preserved across software resets. At least, checking the "magic" header in FSBL always produces randomly looking results that are also different each time I try. Is there a way to preserve contents of AXISRAM5/6 across resets? Do I need to configure something for this to happen (e.g. is there some security feature that resets RAM contents, or the BootROM doing stuff, etc)?

I have disabled the D-Cache and MPU to rule this out as a source of issues, and am also very sure that this is not the usual problem of the C-runtime initialization overwriting the values (since they are different each time, and also because the memory buffer isn't even present in the Linker script - I just access it directly by address).

Thanks a lot, Michael

RomainR. · ‎2025-06-10

Hello @asdfasdf

I just tried your project on my side.

Indeed, the content of AXISRAM5 is lost after a System Reset.

After internal confirmation, this is due to the default shutdown mode of SRAM3 to SRAM6. This corresponds to bit 20 (SRAM SD) of the RAMCFG_AXISRAMxCR registers (with x = 2 to 6).
In RM0486, the reset value of the RAMCFG_AXISRAM3CR to RAMCFG_AXISRAM6CR registers is 0x0010 0000.
As a result, by default, the internal power supply of the concerned SRAMs is turned off to reduce power consumption on VDDCore. Consequently, their content is not guaranteed after a System Reset.

Therefore, important clarifications need to be made on our side in this reference manual, starting from section 10.3.1 "Internal SRAM features" and especially in Table 33 "Internal SRAM features."

Please note that for SRAM1 and SRAM2, the default value of bit 20 (SRAMSD) is 0x0000 0000. However, their content is erased by a system reset.

For your application, you can use the 80kB of retention RAM (between 0x3400 0000 and 0x3401 4000) or the Backup RAM, which is in the VBAT domain (only 8kB !).
Finally, for to store locally your binary, in my opinion, you only have the following options:

Jump your XiP application into code in AXISRAM2 to write your binaries directly into a partition of the external serial NOR flash.
Use another external memory on an FMC, SPI, or XSPI port (NAND Flash or a RAM).

Then reset.

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.

View solution in original post

ahsrabrifat · ‎2025-06-01

If your system has external RAM (e.g., via FMC or OctoSPI), and the reset doesn’t reset the external RAM chip, you could store the binary there.

asdfasdf · ‎2025-06-01

The board does not have any external RAM.

EDIT I also tried AXISRAM1 which also does not work. AXISRAM2 is clobbered by the BootROM, so that's not an option. AXISRAM3/4 seem to be the same as AXISRAM5/6 with respect to their behavior.

TDK · ‎2025-06-01

AXISRAM5 and 6 are not erased on reset according to the Reference Manual. I would recheck your assumption there. Or perhaps your software is performing a software erase on startup.

Set up a hardware watchpoint and see when and where it's modified during debugging.

If you feel a post has answered your question, please click "Accept as Solution".

asdfasdf · ‎2025-06-01

That table is the reason I used AXISRAM5/6 in the first place:) However, I'm just not sure whether there are other components in the N6 that erase the memory that I have missed in the thousands of pages of reference manual. E.g. all the security features, BootROM, etc, there simply are a lot of moving parts on the N6 that are easy to miss.

Concerning you're idea about a software erase on startup being the problem: I do have the following snippet early in the FSBL to enable AXISRAM5/6 (which are off by default) but in case they are already enabled (like after a software reset) I assume that will just do nothing, and in particular not erase them?

__HAL_RCC_AXISRAM5_MEM_CLK_ENABLE();
__HAL_RCC_AXISRAM6_MEM_CLK_ENABLE();

__HAL_RCC_RAMCFG_CLK_ENABLE();
RAMCFG_SRAM5_AXI->CR &= ~RAMCFG_CR_SRAMSD;
RAMCFG_SRAM6_AXI->CR &= ~RAMCFG_CR_SRAMSD;

Chao · ‎2025-06-02

Try to reduce the _estack in .ld file and allocate a block of memory after the stack pointer, then put your new firmware binary there.

asdfasdf · ‎2025-06-03

We have the stack located in DTCM which is not large enough for the full firmware image.

Ozone · ‎2025-06-03

RAM erasure usually happens in the startup code, which often comes as assembler code.
Before any SystemInit() call.

asdfasdf · ‎2025-06-04

@Ozone Thanks, any tips on what to look for in particular? I checked all the initialization code in startup_stm32n657xx.s but it's not doing anything that looks suspicious, mostly just initializing data and bss segments.

Since the values I see in AXISRAM5/6 after reset are different every time I run it I don't think there is some code overwriting/initializing these in a deterministic manner, it looks more like some uninitialized data or a security feature stoping access (I had this problem before on the N6 thanks to the RIF where reads just silently return random values because the security attributes were not configured correctly).

Ozone · ‎2025-06-05

No particular tips, I have no experience with the STM32N6.

I would try debugging, and set a breakpoint at the reset handler.
Most IDEs set this to "break at main" for their debuggers by default.

> Since the values I see in AXISRAM5/6 after reset are different every time ...

As said, I have no experience with N6 devices.
I'm not even sure what technology this AXISRAM is. DRAM or PSRAM might lose their contents during a powered reset, and show random contents.