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.

[flyer31]

Yes, I also checked this recently, but already some time ago, and finally decided to best place a 3 pin 1.28mm header somwhere at the very edge of my PCB with STLINK connect. So for complete firmwire updated it is necessary to open the equipment and connect ST LINK.

All my device have I2C connection - so I2C would be nice, if it would have some "miraculous" way to open... . But such "miraculous" doors of course also anyway are risk for "bad access" by possibly unauthorized users... . Especially if this "miraculous door" is defined by STM for the complete chip family, it will be in fact no "miraculous door" any more but somehow a "well-known door"... :).

But for user adaption I use Lua scripting, and I now use the upper half of memory for my Lua ASCII scripts, and the "hard firmware" resides in the lower bank, so like this all fine for me (except of course that there would be need of firmware update of the "hard firmware", but I hope this will NOT be necessary... this anyway has to be tested very thoroughly as easily catalstrophic things can happen, if something wrong here).

Lua is very nice for these applications ... with reduced libraries this uses only 50kB of machine code / ROM, and with full libraries ca. 110kB, so it is fully included in this 250kB lower bank without problems. And size of typical Lua ASCII scripts is in the range of 10...50kB, so this also fits nicely in the upper 250kB page... . The nice thing about Lua is, that being defined 1990, it basicly is somehow a nice "mix of C and basic" seen from user side (mainly very similar to C but without any dangerous user access possibilities to pointers), from firmware side it integrates very easy into C programs (complete source code available), and it has the Lua interpreter already included in this 50kB of firmware machine code, which somehow is very miraculous (alternatives like Phyton need MegaBytes of machine code).

[Bubbles]

Hello @BMcK​ ,

I don't know what exactly could go wrong with this way of SRAM cod placement. I've used it in development of this code:

X-CUBE-REF-PM - Reference power mode examples on STM32 MCUs software expansion for STM32Cube (AN4777) - STMicroelectronics

It's not for G4, but in principle it's pretty much the same. Just take care to use SRAM1 or CCM SRAM, as SRAM2 is not capable of fetching instructions on G4.

J

[BMcK]

Hi @JHOUD​ ,

I don't understand how this topic turned to power modes... I didn't experiment nor question. What I was saying is that if in Keil it is easy to use MDK IDE +ARM CC to locate code in SRAM and the scatter file will be auto-generated but for GCC I'm afraid manual update linker script(.ld) is the only option. No, I'm not going to use STM Cube nor any other Eclipse-based tools, but this is yet again my personal problem ;)

[BMcK]

@flyer31​  What tools each one is using is the matter of requirements, personal preferences, skills. Obviously, it is always more than one way of achieving the desired goal. Good luck with your design. This is also out of the scope of this topic.

[Bubbles]

Hi @BMcK​ ,

it's not the power mode examples that matter, it's just that the code also includes Keil IDE project that places a lot of binary in SRAM. You may want to take a look. And I do not think it's a bad thing to prefer quality tools that Keil provides. Not to mention that Mr. Keil himself is a great person. The linker scripts for Keil ARM IDE are called scatter files and they are a great tool. I highly recommend trying them.

J

[BMcK]

@JHOUD​ You are preaching to a choir. Unfortunately, I have to develop tools for those who are using Cube+GCC which I'm trying to avoid and quite inexperienced with. That's why I'm asking how to do what they want with what I like, thus asking probably stupid questions.

[Bubbles]

@BMcK​  - sorry, I was confused the whole time and misunderstood you needs. Then you should really check out the SW package I linked earlier - it's the same goal of code being partially in SRAM implemented in IAR, Keil and Eclipse based GCC tool. You will easily see how the basic liker settings translate between the tools.

J