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;

[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.