File Transfer on EtherCAT - FoE, firmware update using XMC4800

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

cross mob
Not applicable
Hello,
following the instructions on Beckhoff pdf EtherCAT Slave Slack Code Guide, I activated on SSC Tools:

  • BOOTSTRAPMODE_SUPPORTED 1
  • FOE_SUPPORTED 1
  • FOR_SAVE_FILES 1


The file ecat_def.h is created by SSC Tools with the right options.
On TwinCAT, when you select the device and click on "online", it displays the state mode of the slave and there is a button to put a file on the slave or retrieve a file.

How can I create a .efw file ( Ethercat firmware) ?

I tried to put on the slave a simple txt file, but it didn't work, saying the microcontroller is not in bootstrap mode while I click on boot it inside twincat menu. I had the error 0x8009.
And when the XMC4800 is in OP mode, when I download a file on it, I don't have an error but I didn't get an success message either.

Do you know where the downloaded files are on the XMC4800, to open them ?

There is a MAX_SIZE_FILE, define by default at 0x180. In which unit is it expressed ?


Thank you in advance,
Nicolas
0 Likes
21 Replies
Not applicable
Any help please ?
0 Likes
Not applicable
I also hope to see an answer, eventually my project will need to implement FoE.
0 Likes
Not applicable
Is there is somebody with the knowledge and willing to share ?
0 Likes
User12537
Level 1
Level 1
Hello, my name is Dirk. I have the same problem when trying it with the "XMC4800 EtherCAT APP SSC Firmware Update Salve Example".
After Setting the Slave in Bootstrap Mode I click the button Download from TwinCAT3 -> Select the file -> Insert passkey "beefbeef" -> get following error:
"Failed to download file to '...' (1001). FoE Err(0x8009).
Thanks for any help!
Regards, Dirk
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Are you using the example ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 example downloaded from http://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html?

Regards,
Jesus
0 Likes
User11975
Level 1
Level 1
Just want to add my 2 cent.

The example works great, and has a proper explanation for creating a .bin file you can transfer to the slave, but there are some small traps.

If you end up in a state where the slave has to erase during the update, the download will fail with a timeout.
Use TwinCAT, with a supported network adapter.
Stay with TwinCAT until everything works, I tried with SOEM and there seems to be a small bug in what SSC Tool writes to eeprom and what SOEM reads, it's possible to fix, but it's not something you want struggle with before your FoE implementation actually works.
0 Likes
User12356
Level 1
Level 1
First reply posted Welcome!
Hi,

I struggled with the same issue and ended up with the error "Failed to download file to '...' (1001). FoE Err(0x8009)" when I tried to download the .bin file over FoE.
But after I carefuly read the touroial PDF I managed to get it up and running.

In the tutorial PDF (Getting Started - XMC4800_Relay_EtherCat_APP_FWUpdate_Slave_SSC_Example) it says you have to modify the function "APPL_Application()" and "APPL_StopMailboxHanler" in the XMC_ESC.c file. BUT this is not the only generated Code you have to modyfie. Ist not specialy mentioned, but you also have to modify the function "FOE_Write(...)" and "FOE_Data(..)" in the foeappl.c file. When you compare the generated Code from the SSC Tool with the one pictured in the PDF you will find the difference 😉

Regards
Simon
0 Likes
User16372
Level 1
Level 1
Hello Developers,
I have a working firmware update code that is based on the ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 example downloaded from https://www.infineon.com/cms/en/product/promopages/aim-mc/dave_downloads.html.
The firmware initially worked fine and I was able to perform FW update, as I was adding and changing stuff, the fw was becoming unstable and had weird behavior. This behavior was loss of static const data, that we all know is not possible, causing lockup.
So for this reason, I start to suspect that there is some kind of memory overlap. After doing the math again, I realized that in the linker_script.ld file that is shipped with the ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 example the length of the FLASH_1 that is the area of firmware the length is set to
0x001E0000
but according to the documentation of the example the application should take XMC_FLASH_SECTOR_8 till XMC_FLASH_SECTOR_11 that give a length of
0x000E0000: 896 KB that matches the one referred in the documentation see picture attached3683.attach

Changing this fixed my weird issues but would be nice if infineon can check if my point is valid.

The problem from my side is, that if this fixes the problem I dont understand why was even happening. I was using only 2% of the memory so definitely I was not even close to the real length.
Is it possible that the linker is not actually placing the data in the beginning of the FLASH_1 sector but scattered around?
0 Likes
User16529
Level 4
Level 4
First solution authored
Hi pilias! I've set the flash lenght to 0x000E0000 both in FLASH_1_cached and FLASH_1_uncached, but it doesn't work, the CPU doesn't start.
0 Likes
User16372
Level 1
Level 1
I never had the problem the CPU not starting because of this. Your problem should be something else.
The most common reason the firmware not to start is if you forgot to flash the bootloader before. This is happening because by default the CPU will start with the program pointer at 0x08000000 but will not find the firmware there. Ideally the bootloader will be there and will redirect the program pointer to the FW that is ussually 0x08020000
Hope it helps
0 Likes
User16529
Level 4
Level 4
First solution authored
Thank you for your reply!
I flashed the bootloader inside the memory as first thing, but the CPU still not starting. Do you think that put the bootloader code inside the main of the FoE project would be a good deal?
I mean somenthing like this



int main(void)
{

firmware_size_bytes = (START_ADDRESS_BACKUP_PARTITION + INFO_OFFSET / 4)[63];

if ( (firmware_size_bytes > 0) && (firmware_size_bytes < APP_PARTITION_MAX_SIZE) )
{
if ( FLASHPROG_CRC32_check(START_ADDRESS_BACKUP_PARTITION, firmware_size_bytes) == FLASH_OK )
{
FLASHPROG_Init(START_ADDRESS_APPL_PARTITION, APP_PARTITION_MAX_SIZE, FLASH_OPT_ERASE, FLASH_OPT_CHECK);
FLASHPROG_Data(START_ADDRESS_BACKUP_PARTITION, firmware_size_bytes);
FLASHPROG_Close();

if ( FLASHPROG_CRC32_check(START_ADDRESS_APPL_PARTITION, firmware_size_bytes) != FLASH_OK )
{
BL_Normal_Restart();
}
else
{
FLASHPROG_Delete_physical_sector(XMC_FLASH_PHY_SECTOR_4);
}

}

}

ptr_backupdata = START_ADDRESS_BACKUP_PARTITION;
while( ptr_backupdata < (START_ADDRESS_BACKUP_PARTITION + BACKUP_PARTITION_MAX_SIZE / 4) )
{

if(*ptr_backupdata != 0)
{
FLASHPROG_Delete_physical_sectors(ptr_backupdata, 1);
}
ptr_backupdata++;
}

BL_FlashABM0_Restart();

}

while(1)
{
MainLoop();
}




Whit linker_scritp like this


MEMORY
{
FLASH_1_cached(RX) : ORIGIN = 0x08000000, LENGTH = 0x00200000
FLASH_1_uncached(RX) : ORIGIN = 0x0C000000, LENGTH = 0x00200000
PSRAM_1(!RX) : ORIGIN = 0x1FFE8000, LENGTH = 0x18000
DSRAM_1_system(!RX) : ORIGIN = 0x20000000, LENGTH = 0x20000
DSRAM_2_comm(!RX) : ORIGIN = 0x20020000, LENGTH = 0x20000
SRAM_combined(!RX) : ORIGIN = 0x1FFE8000, LENGTH = 0x00058000
}
0 Likes
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
First of all the example works out of the box if you follow the instructions exactly.

Please check slide 22 which explains how bootloader and application executable interact with each other.
First you should download the bootloader to get your application executable started from bootloader.
Of course, as long as you did never intially downloaded any application executable, bootloader will start anything which is located @0x0C020000.
So the CPU might hang.
Before starting to download anything you might want to erase the complete flash using J-Flash Lite from Segger.
By this you make sure no old "fragments" of code are remaining inside EEPROM-emulation, backup or application executable.

But let me confirm the finding of Jul 30th, 2019*11:51 AM #9 pilias.
The size of the FLASH1 region inside ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 must be set to 0x0e0000.
Otherwise you will not get warned during linking if the application executable is too big.
However for the original example this issue does not show up, because the application executable is far too small.
Please note inside project settings the linker_script_IAP.ld is in use and not linker_script.ld.
So fixing inside linker_script.ld will not do the job.
This is done this way, because linker_script.ld is re-generated with every code generation of ECAT_APP and otherwise would be overwritten.

Another thing is, that in the past there was a bug inside flashprog.c.
If you find the following history at the top of flashprog.c you already have the latest version:
* History:
* V1.0 01.01.2016 initial revision
* V1.1 08.01.2019 bugfix inside Flash_lCheckPhysicalSectorNumberInRange which
* identified wrong sectors to be in range
Otherwise download the latest version of the example.
Also this bug did not show up for the small sized executables of the example.

Unfortunately until today, this fix was provided inside the project ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 only but did not make it into ETHCAT_FWUPDATE_BOOTLOADER_XMC48.
So please copy the file from ETHCAT_FWUPDATE_SSC_APPLICATION_XMC48 to ETHCAT_FWUPDATE_BOOTLOADER_XMC48 to apply the fix also for the bootloader until we relase a new version of the example.
0 Likes
User16529
Level 4
Level 4
First solution authored
I've downloaded the latest version of the example. This what I've done:

- use the linker_script_IAP.ld in the application project
- erase the flash with Lauterbach Trace
- flash the bootloader code with Lauterbach Trace
- flash the application project code avoinding to erase the bootloader partition with Lauterbach Trace

I can see memory partition with TRACE32 tool:

- 0x08000000 and 0x0C000000 store the bootloader
- 0x08020000 and 0x0C020000 store the application


Now I have both bootloader and application code inside the flash, so I run everything and I expect to see my application running, but the CPU doesn't start and the TRACE32 says "running (sleeping)".

The application code is at address 0x0C020000, so the booloader should make it run, isn't it?
Maybe it stucks because there is no firmware size stored at the address (START_ADDRESS_BACKUP_PARTITION + METAINFO_OFFSET / 4)[63] already. I see in the main bootloader function that it retrives firmware size from this addres, but it will be stored only after FoE download. Could it be the problem?
0 Likes
User17351
Level 1
Level 1
Hi,

I've just been giving this a go over the last couple of days too. I have found that it works when the bootloader app is in debug mode but not when it is in release mode.

I used nm to check the memory layout of the debug vs release .elf files. The release .elf (with optimizations turned on) had stripped the ABM0_Header variable.

I have changed my declaration of the variable to include the "__attribute__((used))" attribute so that it is not compiled out. e.g.:


/****************************************************************
* LOCAL DATA
***************************************************************/
static const ABM_Header_t __attribute__((section(".flash_abm"))) __attribute__((used))
ABM0_Header = {
.MagicKey = ABM_HEADER_MAGIC_KEY,
.StartAddress = 0x08020000, /* Start Flash Physical Sector 1 */
.Length = 0xFFFFFFFF,
.ApplicationCRC32 = 0xFFFFFFFF,
.HeaderCRC32 = 0xEF423163
};



On a second note, I also found that my project settings got a bit corrupted when following the step to use the linker script file "linker_script_IAP.ld" in DAVE 4.4.2.

When I set the "ARM-GCC Create Flash Image" command line pattern field in the project settings it also changed the "ARM-GCC Create Listing" and "ARM-GCC Print Size" command line pattern fields. I needed to manually revert these changes out of the .cproject file to get them working stably again.


Lastly, I noticed that the updated "linker_script_IAP.ld" file from the example has also modified the position of *(vtable) and has removed __text_size and eText. What do these changes do?


Regards,
Graeme.
0 Likes
User18194
Level 1
Level 1
Hello every,
I have another issue with the firmware update example. Slide 26 tells us to set FOE_SAVE_FILES = 1. However this setting does not show up in my SSC Tool.

Could you please show how to turn on FOE_SAVE_FILES setting?

Many thanks,
Hieu
0 Likes
User17351
Level 1
Level 1
Hi,

From what I understand, the example is for SSC v5.11. SSC v5.12 no longer requires the setting.

Regards,
Graeme.
0 Likes
User16529
Level 4
Level 4
First solution authored
Just write this in your ecat_def.h file


/**
FOE_SAVE_FILES: If set incoming Files are stored in "aFileData" max file size is set by MAX_FILE_SIZE. */
#ifndef FOE_SAVE_FILES
#define FOE_SAVE_FILES 1 //This define was already evaluated by ET9300 Project Handler(V. 1.4.1.0)!
#endif


/**
MAX_FILE_SIZE: Maximum file size */
#ifndef MAX_FILE_SIZE
#define MAX_FILE_SIZE 0x186A /*= 100k*/
#endif



And make sure to have this in the foeappl.c


/*-----------------------------------------------------------------------------------------
------
------ internal Types and Defines
------
-----------------------------------------------------------------------------------------*/

#define MAX_FILE_NAME_SIZE 0x0500




/*-----------------------------------------------------------------------------------------
------
------ Module internal function declarations
------
-----------------------------------------------------------------------------------------*/

/*-----------------------------------------------------------------------------------------
------
------ Module internal variable definitions
------
-----------------------------------------------------------------------------------------*/
UINT32 nFileSize;
UINT32 nFileWriteOffset;
#if FOE_SAVE_FILES
CHAR aFileName[MAX_FILE_NAME_SIZE];
#if MBX_16BIT_ACCESS
UINT16 MBXMEM aFileData[(MAX_FILE_SIZE >> 1)];
#else
UINT8 MBXMEM aFileData[MAX_FILE_SIZE];
#endif
#else
UINT8 DataValue = 0x00; //Used to fill upload file with dummy data
#endif
0 Likes
User18194
Level 1
Level 1
GraemeF wrote:
Hi,

From what I understand, the example is for SSC v5.11. SSC v5.12 no longer requires the setting.

Regards,
Graeme.


Thank you GraemeF!
I verified that the project could be compiled and tested successfully without FOE_SAVE_FILES setting.

Regards,
Hieu
0 Likes
User16529
Level 4
Level 4
First solution authored
Hi!
several months ago I was able to solve my problems with FoE and everything works fine till today. Unfortunately, at the end of the download I get the error 0x800B (ECAT_FOE_ERRCODE_PROGERROR) and I don't why it happens.
It happens in the function FLASHPROG_Data in flashprog.c, when it tries to write meta_data (which contains the size of the file .bin)


/* Check for programming errors */
if (gl_flash_check_prog == FLASH_OPT_CHECK)
{
for (uint32_t offset = 0; offset < 64; offset ++)
{
if ( gl_flash_write_address[offset] != ((uint32_t*)gl_flash_page_prep)[offset] )
result = FLASH_PROG_ERROR;
}
}


Does anyone have any advise?
Thank you!
0 Likes
User18369
Level 2
Level 2
Can someone explain me to following line of code :

firmware_size_bytes = (START_ADDRESS_BACKUP_PARTITION + METAINFO_OFFSET / 4)[63];


I don´t understand the [63].... Is this an array? is this just multiply by 63 ?

I have the problem that my Bootloader ends in a Hard Fault if I debugging this line of Code....
Since yesterday my Bootloader Application doesn´t work anymore - without changes..... I only did change the optimization level in ARM-GCC C Compiler... but also changed it back... Could be my Flash corrupted ?
0 Likes
User18369
Level 2
Level 2
florianweber31 wrote:
Can someone explain me to following line of code :



I don´t understand the [63].... Is this an array? is this just multiply by 63 ?

I have the problem that my Bootloader ends in a Hard Fault if I debugging this line of Code....
Since yesterday my Bootloader Application doesn´t work anymore - without changes..... I only did change the optimization level in ARM-GCC C Compiler... but also changed it back... Could be my Flash corrupted ?


Ok I think it have to be an array. But I don´t understand the calculation then.:
* START_ADDRESS_BACKUP_PARTITION (uint32_t*)0x0C100000
* METAINFO_OFFSET (1024 * 1024 - 256)
* firmware_size_bytes = (START_ADDRESS_BACKUP_PARTITION + METAINFO_OFFSET / 4)[63]; = (0x100000 + (1024 * 1024 - 256) / 4) = 1310656 (or in HEX 0x13FFC0) ( Ignored the Offset of start 0x0C000000)

But if i have a look in the pdf of the Example of EtherCat Update the Adress must be 0x0C1FFF00 and not 0x0C13FFC0

Can someone explain me this ?
0 Likes