STM32N6: Retain RAM contents across resets for OTA firmware updates

[asdfasdf]

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

[ahsrabrifat]

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]

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]

 

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.

[asdfasdf]

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;

 

[Ozone]

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

[Chao]

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]

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

[asdfasdf]

I created a minimal project for the N6 Discovery Kit to show the issue, and attached it to this post. It does not even need an Appli and XIP, just the FSBL is enough. All it does is enable AXISRAM5, check whether the magic number is there at a specific location. If it is, it blinks the user LED quickly for 10 seconds, clears the magic number and reboots. If the magic number is not there it blinks slowly for 10 seconds. All the code custom code is in main.c (in particular, I did not touch the linker script which configures AXISRAM2 as main memory).

Note that this has to be run from Flash (i.e. the DK-board switched to Flash-boot mode). Running from the debugger is not possible because of the Software-triggered system restart.

I would be really happy if someone from ST with experience with the N6 (maybe @RomainR. or @B.Montanari ?) could have a look at this. If this really is not possible to do with the N6 then I think this is a pretty severe limitation of the chip.

Thanks a lot!

[RomainR.]

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,

 

[asdfasdf]

Thanks for the confirmation, Romain!

We decided to change our approach and run the flash writing part of our software stack from RAM instead, so that we don't need to restart the system and rely on ram retention. So far it's working pretty well.

Best regards,

Michael

[alister]

You've evidently plenty of RAM.

Could you change your implementation like this?

• execute the app from internal SRAM, not XIP
• encrypt/sign the app, including any necessary headers, at build time
• reserve two app areas in flash
• during download, write the app direct to flash, to app area that's not being executed
• during boot, either select one of app areas to execute, or install any downloaded app to an active area and then execute that.

As it's OTA, the interleaving flash write times aren't likely to problematic.

As the download's written direct to flash, your app's max size would be larger.

Please share what you decide to do.