XM4800 Data protection in flash during EtherCAT FW Update

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 1
Level 1
Hi all,

I am using an XMC4800 with EtherCAT. I would like to store “persistent” data in the flash which should still be stored after a firmware update. I use the same structure as in the FW Update Slave Example of Infineon:


The bootloader executable is stored in physical sector 0.
PS4 is erased after a firmware update because the emulation data might change.
I wonder if it somehow possible to store my “persistent” data on e.g. PS12? I haven’t brought it to run so far.
Or is there another possibility? I have also tried to store data on the XMC_Flash_Sector_7, but the data in this sector is always deleted after erasing XMC_Flash_Sector_4.

2 Replies
Level 2
Level 2
5 sign-ins First question asked 5 replies posted

Sorry for reopening this old thread.

Does anyone have a solution for this problem. I'm having the same problem which I can't figure out.

50 replies posted 25 replies posted 10 replies posted
should be quite simple.
Inside the example the EEPROM data is intentionally erased for the reason, that the new firmware you just download might not be compatible to the EEPROM data of the old firmware.
Therefore, by erasing the EEPROM, with the very next startup of the new firmware, data from the new binary will be installed.
If you just do not erase the EEPROM data the new firmware will use the EEPROM data of the old firmware.
For this it should be made sure, that the new firmware is compatible and can work with the content of the EEPROM of the old firmware.
Otherwise you node might not become operational after the update.
If this is the case, you just need to remove this code

/* delete EEPROM content (2nd 64k sector) */

called inside main() of the example.

We only have the following Physical Sectors: PS0, PS4, PS8-15.
There is no PS7.
If you need portions of the EEPROM data of the old software inside the new software it is much more complicate.
You need to store the old "EEPROM"-data in any physical sector for later use and modify the software so that this PS is not used for the firmware download.
This will limit the size of the available backup-buffer and therefore the available size for the binary to download. So you have to modify the SW to avoid overwriting.
In this case I would propose you still delete PS4 which will trigger later installation of the new data into EEPROM with the very first startup.
After the new data has been stored inside EEPROM you can merge your old custom data into the new EEPROM data.
The trigger to do this merge you can find inside ecat_ssc.c.
Inside function ECAT_SSC_Init(ECAT_SSC_t *handle) it is checked if the EEPROM is empty:
if (E_EEPROM_XMC4_IsFlashEmpty())
--> If flash is empty the new EEPROM-data from the binary is installed inside EEPROM (PS4).
Now there comes the tricky part:
You need to merge the data you like to have from the copy of the old EEPROM data into your new EEPROM data.
For the next startup flash will no more be empty and the data from PS4 will be used.

To be honest: I would advice to avoid the merging and only either use
1. compatible EEPROM content
2. do a complete update with the new EEPROM data generated by the SSC tool.

btw: Make sure to use the latest version of the example (download from within DAVE) based on SSC 5.12.

Kind Regards