Loading...
 

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 two short videos (registration required) highlighting:

System Workbench for STM32


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

I’m working on a project based on a STM32F722VET using the HAL drivers. I have a few sensors that I read and a calibration routine to get the best values out of them. I want to store the calibration coefficients in non-volatile memory so that I don’t have to go through the calibration routine every time I power on the device. I was planning to use the EEPROM emulation code provided by ST, but they don’t have a version for the F7.

I have used the F3 version on a previous F3-based project I was working on and it worked fine. I set the two pages to be the last two pages of flash and had no issues. The F7 breaks up its memory into 8 variable sized memory ‘sectors’ rather than a bunch of equal sized ‘pages’ like the F3. I believe the F4 also uses ‘sectors’ because the EEPROM emulation code for the F4 references ‘sectors’. However, the F4 version is based on SPL, not HAL. I was thinking I could cobble together an F7 version by copying bits and pieces from the F3 and F4 version, but before I start that project, I have another issue.

The F722VET has 512kb of flash broken into 8 sectors as follows:
S0-S3 : 16kb each
S4  : 64kb
S5-S7 : 128kb each

By default, system workbench writes the application memory starting at the beginning of sector 0 (0x08000000). EEPROM emulation requires blocking off two sectors to work, but I don’t want to use the last two because that would be half of my flash, I need that space for the application. I’d like to use the first two sectors since they are small and then use sectors 2-7 for the application. In order for this to work, I have to change where system workbench writes application memory during programming.

I found this related postQuestion and tried some of the things mentioned.

Under “STM32F722VETx_FLASH.ld”, I changed:

**********************
MEMORY
{
RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 256K
FLASH (rx)  : ORIGIN = 0x8000000, LENGTH = 512K
}
**********************
to
**********************
MEMORY
{
RAM (xrw)  : ORIGIN = 0x20000000, LENGTH = 256K
FLASH (rx)  : ORIGIN = 0x8008000, LENGTH = 480K
}
**********************

Under “system_stm32f7xx.c”, I changed

#define VECT_TAB_OFFSET 0x00
to
#define VECT_TAB_OFFSET 0x8000


Then I erased the chip, did a clean build, and reprogrammed. Starting a Debug instance worked but if I just hit the “Run” button instead, it does not work. I looked at the memory using STM32 ST-LINK utility and I noticed that Sectors 0 and 1 (0x08000000 - 0x08007FFF) were no longer blank (all FFF...FF). The first bytes up to about 0x08000080 were occupied and then the rest were all 0s. I also noticed that the ASCII code for the first few bytes includes “ELF” which is suspicious. After that, at 0x08008000, the rest of the code begins as expected (with 0x20040000 as the first entry which I believe is what it should be). It’s OK if the first sectors get erased during programming because I don’t need to store calibration coefficients through reprogramming, but of course I do need the program to run without debug mode.

What steps have I missed? I feel like it might be related to the “isr_vector_start” line mentioned in the post I referred to before. But I don’t understand what that is or what it does.

Thank you!

France

Hi,

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)

France

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);
} >FLASH

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.

Thanks,
Ben

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.