SW4STM32 and SW4Linux fully supports the STM32MP1 asymmetric multicore Cortex/A7+M4 MPUs

   With System Workbench for Linux, Embedded Linux on the STM32MP1 family of MPUs from ST was never as simple to build and maintain, even for newcomers in the Linux world. And, if you install System Workbench for Linux in System Workbench for STM32 you can seamlessly develop and debug asymmetric applications running partly on Linux, partly on the Cortex-M4.
You can get more information from the ac6-tools website and download (registration required) various documents highlighting:

System Workbench for STM32

Changing flash program start address in order to implement EEPROM emulation on STM32F722VET



The problem with your setup is that, when resetting the board, the vector table address is not taking the VECT_TAB_OFFSET value into account: this value is used to relocate the vector table in SystemInit, so after your code has started...

You must keep the vector table in place, at address 0x8008000 (offset 0 in the flash), as it is there that the CPU will read its reset vector (in fact the FLASH is remapped at address 0 at reset time, and that’s there it is read by the CPU during the reset sequence).

So you must at least have the two first words of the vector table (Master SP and reset vector) at address 0; the whole of the vector table may be relocated as you do, as there will be no exception before you execute SystemInit and so relocate it.

For this to work you must keep the original memory definition but add a special section at address 0, containing this minimal vector table and, possibly, initial values for your persistent data; this section must have its size manually set to 32kB so that the rest of your code goes at 0x8008000.

Then, of course, your EEPROM emulation must always reprogram the fisrt 8 bytes of the flash with the reset vector (and hope you never crash between erasing the first sector and reprogramming the reset vector...)

A safer, and simpler, way to go would be to keep sector 0 for the vector table only, use sectors 1 and 2 for EEPROM emulation, then place your application code starting at sector 3. Depending on the size of your application sections you may place some code, read-only data or data initialization values in sector 0 (or sector 0 and 1 using 2 and 3 for EEPROM emulation) so that you don’t waste almost 16kB of the first sector,

Hope this helps,

Bernard (Ac6)


Hi again,

To be a bit more precise, reservibg the first 16kB (first sector) and placing there only the vector table can be done by replacing th eline that says
. = ALIGN(4);
at the end of the .isr_vector section by
. = ALIGN(0x4000);
. Then add a 32kB section for your EEPROM emulation before the .text section or align to 64kB and use the last two 16kB sectors for your EEPROM emulation...

Bernard (Ac6)

Hi Bernard,

Thank you very much for your responses! It took me a few tries to get it right, but now I have a solution that works.

I undid all my previous changes, then I changed the last line of the “isr” section to
. = ALIGN(0x4000);

and then added a section between the “isr” section and the “text” section

.eeprom :
. += 0x7500;
. = ALIGN(0x4000);

Now when I program the chip it runs normally and sections 1 and 2 (0x8004000 through 0x800BFFF) are blank. Next step, getting EEPROM emulation to work on the F7.


I finished making the changes to the EEPROM emulation drivers so that they now work with my F7. I’ve attached the edited files here in case anyone finds this and wants to use them. I’m not making any promises about them, so use them at your own risk.

edit: Whoops, I found that ST actually does include EEPROM emulation drivers for the F7 in the Cube package, i was just looking in the wrong place. Oh well, at least I learned some stuff in the process.