STM32R446RE: can backup sram be used for the stack and variables in common?

[DHase.1]

I am looking at strategies for updating flash over CAN for the F446 (STM32F446RET6). A small loader program resides in addresses 0-0x8000, and loads the addresses above 0x8000 while there is other CAN traffic running. (This has been done and works with the STM32L431.) The knotty problem with the F446 is that the last three flash sectors are 128KB and the normal sram is 128K. If the procedure requires updating any addresses in flash and preserving the data not in the update, then the existing data in a sector needs to be saved before the erase and write. Reading in these 128K sectors takes all of sram.

One approach would be to set the stack vars in common to the backup sram. After reading the various posts on backup sram, it looks like it would work on the F4 series, however I wonder if interrupts (and the possibility of tail-chaining) would work correctly, hence the question.

An alternative would be to save the 128K sector data in the first 124K of flash and the remaining 4K in the backup sram. This adds a bit of logic to the program, however the stack, etc., would then be operating with the normal flash.

There are all sorts of variations if the requirements can be relaxed a bit, e.g. rearrangement of memory layouts so that sectors 0-4 preserve not-updated data, etc. At the moment, my interest is with the backup sram and ways it can and cannot be used.

[Pavel A.]

Just test it. Should work. Maybe use MPU to tweak  attributes of backup ram.

[tjaekel · Accepted solution]

Sure, you could use Backup SRAM as stack memory (via linker script to set stack top address to it).
There are some things to consider:

1. Backup SRAM must be enabled first:
   You have to do on startup code, to enable Backup SRAM as first as possible.
   You have to make sure, that not any function using stack (e.g. functions called with local variables, stored on stack) is called before you have really done the Backup RAM initialization.
   Potentially: you should enable Backup SRAM already in the Reset Handler, before calling any other function, e.g. main(). It might crash before or in main(), when you need stack in those functions and those are executed before Backup SRAM was enabled. (You have to know which functions are called before Backup SRAM is enabled, if they would use stack already before it becomes available. - it will crash. You have to consider "what is going on startup until Backup SRAM enabled")
   Depending on your MCU: you might need to enable the power (and clock) for a domain (e.g. D3) first, before you can enable and access Backup SRAM (check the datasheet and bus matrix). Some MCUs need to power on D3 domain manually.
2. The Backup SRAM is not so fast as any other memory: it goes via the bus fabric and at the end via AHB (not AXI). See the bus fabric matrix (it is a pretty slow path for data).
   It might be slower (OK) and might have some limitations (be careful), for instance: 64bit word access is not possible, some DMA paths are not possible.
3. I have realized once on one of my STM32 boards: even I tried to set the MCU core clock to the nominal (max. supported) MCU speed, the SRAM was not reliably working.
   I had to lower the entire MCU core clock (and system) just to be able to access Backup SRAM without bit errors.
   So, if somethings fails with using Backup SRAM: try to lower entire system (MCU core) clock (on boot).
   Later, after all done and changing to another stack: you can increase the system core clock.
   BTW: I would suggest to set the stack (SP register) after all booting done, to another "regular" SRAM. I would not keep running on Backup SRAM for stack memory (too slow with access limitations).

Good luck (by "trying" this approach).