How to backup/restore value of variables in STM32N6570-DK board

[Louie88]

Hello,

I have some setup variables in my app which should retained while the power is switched off. Normally I would use the dedicated Backup RAM, but the board does not have backup battery, battery socket, not a battery connector. The Backup RAM is not usable with STM32n6570-DK board.

The MCU does not have internal flash memory with backup area. (This worked with H747 and H723 MCUs) The board has an external 1Mbit flash memory controlled by OCTOSPI so I might store data in the external flash. I need max 512 bytes only. This 512-byte backup should be placed to the end of the external flash.

Can anybody advice how to do this?

Best regards,

Louis

[TDK]

What are you looking for in particular? This is not a code writing service.

Erase the page of flash, write new values. Re-read it on startup. If power shuts off during writing, the data can be corrupted so sometimes two pages are used.

See the EEPROM emulation library for ST's solution for this. It's not set up for the N6 as it doesn't have internal flash, but it could be adapted.

How to use EEPROM emulation on STM32 MCUs - Application note

[Louie88]

Just for sure. I already solved flash based back/restore settings in H747I-DISCO, H723-Nucleo and U5-DK2 boards. All of these had internal flash memory. The N6 has external flash (128MB) only controlled via XSPI and I have never used Octo SPI, I do not know how to initialize it, even I am not sure whether it has Memory Mapped mode. I thought I ask it from the community. It was not a good decision.

[Andrew Neil]

So your real question is, "how to write to XSPI Flash?", then ?

PS:

Does this Knowledge Base article help: Overall FAQs for QUADSPI/OCTOSPI/HSPI/XSPI ?

[Louie88]

I thought an answer something like this...

This will be complicated...

Your idea to use XSPI2 to store your settings in the external flash is problematic.

1. The XSPI2 is used exclusively by the FSBL domain. Practically it means that the Appli project "does not see" the initialized hxpsi2 handle and SPI2 is not enabled in Appli.
2. You cannot initialize XSPI2 from Appli. This would yield to HARD_FAULT.
3. Why your TouchGFX "sees" the external flash memory via XSPI2? Actually, it can ready only it because finally the external flash is placed in Memory Mapped mode, so it is readable like any other ROM or RAM, but TouchGFX cannot write into it. TouchGFX only reads the assets stored in eternal flash and it does not use XSPI2.
4. This means you can erase and write the top block settings of the external flash exclusively from FSBL project, but you can read the top block (settings) from Appli project any time.
5. Shortly, currently you cannot save settings into the flash from Appli project but you can read it any time.

The probable hardware solutions:

1. Add a simple I2C based flash chip to the board. (I can't add new chip to the board)
2. Add battery backup to the board. (The board does not have battery socket, nor battery connector. Battery can be added with removing SB4 and soldering a wire to VBAT side of SB4, or the + side of C28 capacitor, if you're good enough to do it...

The probable software solution:

1. You need a Shared RAM area what both the FSBL and Appli can read and write.
2. You need a custom IPC_Request structure implemented in FSBL and Appli.
3. When you would like to save your settings then you add your settings data to the IPC_Request and set its command member to "save" ("erase and save")
4. Appli triggers an interrupt in FSBL.
5. FSBL stores the shared IPC_Request structure.
6. In Main loop when FSBL notices that the save settings is requested then it erases the top block of external flash and programs the provided data to the top block.
7. Finally FSBL sets the status code either to Error or Success depending on it could or couldn't save the sent data.

Louis

[Louie88]

Sorry, it was a nice idea, but it will never work. After the FSBL loaded the Application code into RAM then all control will be set too Application project. The FSBL does not run any more. So, sending an interrupt to FSBL (or polling IPC_Request.saveRequest = true in main loop of FSBL will never work. I think I give it up and I try to save the settings to an SD card.

Louis