STM32G4 flash write/erase

[BMcK]

I'm quite confused. The RM0440 states: "Note that read-while-write capability (or RWW) is only supported when the dual-bank architecture is active. This enables programming or erasing one bank while executing code from the other bank." Okay, for me, it means that if a single bank option is selected then it is impossible to write/erase flash executing user code at all. Correct? Then programming and/or erasing flash is possible only for category 3 devices (G431 is out of the picture immediately). The next step is to verify if dual bank mode is selected, then to deal with the page in the alternative to the user code bank.

I wrote a simple example code doing exactly that, but it is inconsistent: sometimes works as expected, mostly does not. I do not use Cube but direct access to the registers. What is wrong with my logic and where should I pay more attention.

Thanks in advance.

[Bubbles]

Hello @BMcK​ ,

the usual practice in single bank device is to set the linker to place the functions that write/erase the Flash in SRAM. That way the code can execute even when the Flash is being manipulated.

J.

[BMcK]

Thank you for the reply.

Basically, you're saying that my understanding is correct.

Could you please point me to a GCC example(I'm a Keil user) of how to locate my flash access functions in SRAM. My guess is that they should be located in some dedicated section, and this section should be located in SRAM.

[Bubbles]

Easiest is to open source file options using right mouse button and set SRAM as memory assignment for code. For finer adjustments you need to build your own scatter file.

J.

[BMcK]

I guess in such a case, all interrupts have to be disabled because who knows in what memory an ISR would be located or which procedure it may call.

@JHOUD​ I also noticed that the GCC option for Keil doesn't let me easily put that file in SRAM. Did I miss something?

[flyer31]

At least this really gets complicated and tricky... the main thing you have to think about in my opinion would be the "catastrophic event" that something mixed up during such an "SRAM flash update" - if you have bad luck, in such case after new power-up the flash might be "mixed up" that much badly, that the controller will NOT start any more normally ... in this case then some "standard user without STLINK" will NOT have any further access, and will have to send back the device to the original manufacturer, so that it is re-programmed by STLINK access as I see it.

But the dual bank architecture looks really VERY nice. In this case this can NOT happen. In our applications I use the uper half for user programs, and the lower half for our own firmware, and this really is very fail-proof as I see it... . Only restriction then is, that you may re-program only half of the memory, but as many new controllers of G4 have a really large ROM of 500kB, you at least have 250kB left for such user programming, which really is fairly nice I think.

[BMcK]

• You're making an assumption that flash bank size is always enough for the user code. It is not always true.
• You don't always have to have an external programmer to fix corrupted flash - ROM bootloader is a decent option.

[flyer31]

1st point of you I agree of course ... if you the program size is that much "scratching the hardware limits", then somehow "bad luck".

2nd point: But if you use ROM bootloader (e. g. I2C bus in my applications would be somehow possible "possibly"... ) ... but then you anyway have to somehow get access to BOOT0 and/or BOOT1 pin? So the "programming user" will somehow have to open the equipment to get access to these pins (and these pins must be "freely accessible" / not used for other things on the PCB? ... this I think would be too restrictive / to cumbersome for me / for possible users of me, in this case I would prefer that they send me back the equipment / sub-device.....). Or is there some way, that this I2C "bootloader channel" is somehow "open by default", just requiring the correct I2C bootloader slaveaddress 0x53 being used on the bus and then some correct I2C initialisation command?

[BMcK]

There are several options to get to bootloader/boot pins, but this is a very different topic outside the scope of this one. I'm at this point exploring all the available options, choosing between flash access and/or external memory. Safety/price/real estate restrictions/complexity and correspondingly dev time: quite a lot of factors to consider.

[BMcK]

PS: the reason my simple example code didn't reliably work was... the Nucleo board I was using did NOT have a boot pin jumper installed while option bytes were changed from the default and that was causing me to get into ROM bootloader...

It is so hard to catch a black cat in a dark room that's not there.