+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 11 to 15 of 15

Thread: File Transfer on EtherCAT - FoE, firmware update using XMC4800

  1. #11
    Beginner Beginner pilias is on a distinguished road
    Join Date
    Jan 2019
    Posts
    5
    Points
    120
    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

  2. #12
    Intermediate Intermediate Janet is on a distinguished road
    Join Date
    Feb 2019
    Posts
    29
    Points
    365
    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

    Code:
    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

    Code:
    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
    }
    Last edited by Janet; Aug 1st, 2019 at 05:46 AM.

  3. #13
    Intermediate Intermediate
    Infineon Employee
    Infineon Employee
    MichaelIFX is on a distinguished road
    Join Date
    Mar 2016
    Posts
    48
    Points
    484.53125
    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.
    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  4. #14
    Intermediate Intermediate Janet is on a distinguished road
    Join Date
    Feb 2019
    Posts
    29
    Points
    365
    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?
    Last edited by Janet; Aug 2nd, 2019 at 06:32 AM.

  5. #15
    Beginner Beginner GraemeF is on a distinguished road
    Join Date
    Jun 2019
    Location
    New Zealand
    Posts
    11
    Points
    145
    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.:

    Code:
    /****************************************************************
    * 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.

+ Reply to Thread
Disclaimer

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.


Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.


Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.