This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: Ethernet Firmware Update

Part Number: TM4C1294NCPDT

Tool/software:

Hi there  

I've tried to build MQTT client when i try to burn it usig bootloader it burns from address 0x4000 and it works well, then i've added the Software Update which pass the control to the bootloader to burn the updated firmware but it burns the code starts from address 0x000 i don't understand this strange behaviour i've copied the same code to boot_demo_emac_flash project (i've just update the boot_demo_emac_flash.c file by the main.c then i added all of the file of MQTT client in boot_demo_emac_flash project 
my question is "Is there any configuration in boot_demo_emac_flash project which resolve this issue ? and if not what do you think the problem is ?

  • I've tried to build MQTT client when i try to burn it usig bootloader it burns from address 0x4000

    Which bootloader is this? Is this the flash-based  bootloader? If you are using the flash-based bootloader then it will program your firmware to 0x4000 if APP_START_ADDRESS is 0x4000 as defined in the bl_config.h file.  See below snippet.

    //*****************************************************************************
    //
    // The starting address of the application. This must be a multiple of 1024
    // bytes (making it aligned to a page boundary). A vector table is expected at
    // this location, and the perceived validity of the vector table (stack located
    // in SRAM, reset vector located in flash) is used as an indication of the
    // validity of the application image.
    //
    // The flash image of the boot loader must not be larger than this value.
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: None
    //
    //*****************************************************************************
    #define APP_START_ADDRESS 0x00004000

    //*****************************************************************************
    //
    // The address at which the application locates its exception vector table.
    // This must be a multiple of 1024 bytes (making it aligned to a page
    // boundary). Typically, an application will start with its vector table and
    // this value should be set to APP_START_ADDRESS. This option is provided to
    // cater for applications which run from external memory which may not be
    // accessible by the NVIC (the vector table offset register is only 30 bits
    // long).
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: None
    //
    //*****************************************************************************
    #define VTABLE_START_ADDRESS 0x00004000

    //*****************************************************************************
    //
    // The size of a single, erasable page in the flash. This must be a power
    // of 2.
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: None
    //
    //*****************************************************************************
    #define FLASH_PAGE_SIZE 0x4000

    then i've added the Software Update which pass the control to the bootloader to burn the updated firmware but it burns the code starts from address 0x000

    Jumping from the application to the bootloader is not different than starting the bootloader to download the firmware the first time. It should update the firmware  at 0x4000 unless you call the ROM bootloader instead of the flash bootloader. See below SoftwareUpdateBegin when you call it in your application. The ROM-based bootloader will always program the firmware at 0x0. 

    //*****************************************************************************
    void
    SoftwareUpdateBegin(uint32_t ui32SysClock)
    {
    //
    // Disable all processor interrupts. Instead of disabling them
    // one at a time (and possibly missing an interrupt if new sources
    // are added), a direct write to NVIC is done to disable all
    // peripheral interrupts.
    //
    HWREG(NVIC_DIS0) = 0xffffffff;
    HWREG(NVIC_DIS1) = 0xffffffff;
    HWREG(NVIC_DIS2) = 0xffffffff;
    HWREG(NVIC_DIS3) = 0xffffffff;
    HWREG(NVIC_DIS4) = 0xffffffff;

    //
    // Also disable the SysTick interrupt.
    //
    SysTickIntDisable();
    SysTickDisable();

    //
    // Return control to the boot loader. This is a call to the SVC
    // handler in the flashed-based boot loader, or to the ROM if configured.
    //
    #if ((defined ROM_UpdateEMAC) && !(defined USE_FLASH_BOOT_LOADER))
    ROM_UpdateEMAC(ui32SysClock);
    #else
    (*((void (*)(void))(*(uint32_t *)0x2c)))();
    #endif
    }

  • No it is Ethernet bootloader (boot_emac_flash) 

  • ok.

    Please tell me if you use the flash bootloader (boot_emac_flash residing at 0x0) to first load the example firmware   (the boot_demo_emac_flash, not your MQTT code) as is , does it succeed? 

    After the boot_demo_emac_flash  is loaded and starts running, press SW1 on the LaunchPad, it is supposed to jump back to the flash bootloader and then reload your firmware again to 0x4000, does it succeed?

  • i first load boot_demo_example and it works well and i update it using LM flasher and it works

  • i first load boot_demo_example and it works well and i update it using LM flasher and it works

    I'm not clear. I want to make sure we are talking the same thing. Here you said boot_demo_example. Do you mean boot_demo_emac_flash?

    I suppose you use the the bootloader (boot_emac_flash) to load the example boot_demo_emac_flash using LM flash programmer through the Ethernet port, correct?

    Once the boot_demo_emac_flash is running, how did you jump back to the bootloader? Did you press SW1 on the LaunchPad? Suppose you did press SW1, did the bootloader reload the boot_demo_emac_flash again? I don't think you answer my question in my prior reply.

  • I'm not clear. I want to make sure we are talking the same thing. Here you said boot_demo_example. Do you mean boot_demo_emac_flash?

    yes

    I suppose you use the the bootloader (boot_emac_flash) to load the example boot_demo_emac_flash using LM flash programmer through the Ethernet port, correct?

    correct

    Once the boot_demo_emac_flash is running, how did you jump back to the bootloader?

    i update the code by LM flasher upon the reception of Magic Packets via ethernet 

  • i update the code by LM flasher upon the reception of Magic Packets via ethernet

    If you can repeatedly update the code through Ethernet port using LM flash programmer then it means the bootlaoder is correcting relashing the firmware to 0x4000. You need to check what is the difference between your own code against boot_demo_emac_flash.  

  • i copy all the folder from MQTT client project to boot_demo_emac and update boot_demo_emac.c by the main.c file of MQTT client and i can repeatedly update the code the problem is i don't why it work here when i transfer the files and it does not work on MQTT client project

  • You need to check the .cmd file if you have set the APP_BASE to 0x4000 for your MQTT project. 

  • yes,it is and i still has the same issue

  • I have no visibility into your MQTT project and I don't know why it works if you copy the MQTT files over to boot_demo_emac_flash project but not working when the MQTT project is a separate CCS project by itself. Have you checked the CCS project settings. Are they the same? Go through each option under CCS Build and ARM Linker and see if any differences between the two projects.