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.

EK-TM4C1294XL: Problem in Ethernet based firmware upgrade functionality using flash based bootloader (boot_emac_flash) and eflash.exe utility.

Part Number: EK-TM4C1294XL

Hi,

I am facing some trouble in upgrading firmware using ethernet bootloader.

First, I flashed boot_emac_flash at mem location 0x0 and boot_demo_emac_flash at memory location 0x4000 using jtag and tried to write the same file at the location 0x4000 using ethernet.

I again got the same error (Unable to start bootp server) in LM Flash programmer. Then I tried switching to another utility eflash.c and which was giving error in bootp_server.c in line no 459 which was to create a socket for the bootp server.To, make changes to this eflash file, I compiled it using make utility in cygwin.

Then, I changed the bootp server port in the eflash.c to 50000(i.e. some random port) bootp client mode to 50002 and tftp server port to 50004 and I was successfully able to send MAGIC packets to udp port 9, and the LED on board stopped blinking, i.e. code succesfully branched to bootloader. But the upgrade did'nt happen(because in the bootloader, the configures udp ports were 67.68 and 69 resp.).

So, I again changed the ports in bootloader code to 50000, 50002 and 50004 resp. and again ran the eflash utility. But, the eflash utility again gives an error: failed to create bootp server socket. 

Does this mean that the ports configured in the boot_emac _flash are conflicting with the eflash utility?

Also, for the whole time dhcp server was on. Can this be a problem?

Also, I tried doing netstat -a and found this:(192.168.1.150 is my laptop ip, 192.168.1.5 is the board ip assigned by DHCP server.)

UDP 0.0.0.0:58952 *:*
UDP 0.0.0.0:62859 *:*
UDP 127.0.0.1:1900 *:*
UDP 127.0.0.1:49664 *:*
UDP 127.0.0.1:59822 *:*
UDP 192.168.1.150:9 *:*
UDP 192.168.1.150:67 *:*
UDP 192.168.1.150:67 *:*
UDP 192.168.1.150:69 *:*
UDP 192.168.1.150:69 *:*
UDP 192.168.1.150:137 *:*
UDP 192.168.1.150:138 *:*
UDP 192.168.1.150:1900 *:*
UDP 192.168.1.150:40000 *:*
UDP 192.168.1.150:40004 *:*
UDP 192.168.1.150:40006 *:*
UDP 192.168.1.150:50000 *:*
UDP 192.168.1.150:50003 *:*
UDP 192.168.1.150:59820 *:*
UDP 192.168.2.96:137 *:*
UDP 192.168.2.96:138 *:*
UDP 192.168.2.96:1900 *:*
UDP 192.168.2.96:59821 *:*



Regards,
Apoorv

  • Hi Apoorv,

     When you run emac_boot_flash bootloader, what did you put into the Client IP Address in the LM flash programmer? I will suggest you revert back to the original emac_boot_flash bootloader bootloader and boot_demo_emac_flash examples and use the LM flash programmer again. 

    Below are the steps you need to take.

    1. Program the TivaWare example such as enet_lwip into the MCU flash via the JTAG interface using CCS or LM flash programmer. 

    2. Run the enet_lwip and you should see the IP addressed printed out on the terminal window. You need to record this IP address. This IP address is dynamically generated by the DHCP server. This IP address needs to be used later when you run the emac_boot_flash example. The reason is that the PC running the LM flash programmer is also a BootP server as well as the TFTP server. The BootP server is static in nature. You need to manually associate a client's IP address with the client's MAC address in a fixed table in the BootP server.  Note the only purpose to run the enet_lwip is to obtain an IP address. Once the dynamic address is acquired it is leased on your network for some hours. You might be able to configure your router to lease an IP address indefinitely. Check with your IT department. 

    3. Program the emac_boot_flash into the MCU's flash via the JTAG interface. You can use the CCS or LM flash programmer to load the code. Note the emac_boot_flash starts at 0x0.

    4. Run the emac_boot_flash bootloader. The emac_boot_flash is supposed to send the BootP request now. However, since you have not yet launched the BootP server the client will just keep sending the request. If you have a wireshark you should see the BootP requests at 1s, 2s, 4s, 8s and so on. 

    5. Open the LM flash programmer. See below. Enter the IP address that you just acquired from running the enet_lwip into the Client IP address field. Next enter the MAC address of your client. If you are using the LaunchPad you should see the MAC address on the sticker at the back of the board. What you are doing here is more like manually updating the BootP server's table of IP address and MAC address association. 

    6. Go to the Program tab and specify the boot_demo_emac_flash.bin as your application program image and hit the Program button. See below. 

    7. Give some time and you should see the download happening via the Ethernet. 

    I cannot answer the eflash questions since I have not used it personally but I think it should work pretty much the same. My understanding is that the Bootp should happen across UDP port 67 and 68. I'm not too sure how it will work or will not work in your network if you choose some random ports. I don't have the knowledge to answer them. I will suggest you redo the example as illustrated above. 

  • Dear Charles, 

    I am working on TM4C1294.

    After running boot_emac_flash (point 3) I am able to successfully download the boot_demo_emac_flash.bin and so I am able to complete your procedure. And I can say it because the LM Programmer gives a positive outcome and I can see the led blinking. 

    If at the end of the point 7 I try to re-program the controller (even with the same boot_demo_emac_flash.bin) the Wireshark log doesn't show any kind of activity between TM4C and LM Programmer (which halts in "Attempting to connect"). What can I check to understand the problem? 

    Furthermore, I can't see the serial output of "boot_demo_emac_flash", but I can see the led blinking and I am pretty sure that the program is running. Do you think is related to the main problem? 

    Thanks for your time,

    Michele

     

  • Hi Michele,

    The bootloader boot_emac_flash is designed to check if the application is already programmed. Since you have programmed the application boot_demo_emac_flash, the bootloader will just jump to the application unless you force the reprogramming via a GPIO pin input. Please refer to the bl_config.h file. Below is a snippet of the header file.

    //*****************************************************************************
    //
    // Enables the pin-based forced update check. When enabled, the boot loader
    // will go into update mode instead of calling the application if a pin is read
    // at a particular polarity, forcing an update operation. In either case, the
    // application is still able to return control to the boot loader in order to
    // start an update. For applications which need to perform more complex
    // checking than is possible using a single GPIO, a hook function may be
    // provided using BL_CHECK_UPDATE_FN_HOOK instead.
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: FORCED_UPDATE_PERIPH, FORCED_UPDATE_PORT, FORCED_UPDATE_PIN,
    // FORCED_UPDATE_POLARITY
    //
    //*****************************************************************************
    //#define ENABLE_UPDATE_CHECK

    //*****************************************************************************
    //
    // The GPIO module to enable in order to check for a forced update. This will
    // be one of the SYSCTL_RCGC2_GPIOx values, where "x" is replaced with the port
    // name (such as B). The value of "x" should match the value of "x" for
    // FORCED_UPDATE_PORT.
    //
    // Depends on: ENABLE_UPDATE_CHECK
    // Exclusive of: None
    // Requries: None
    //
    //*****************************************************************************
    //#define FORCED_UPDATE_PERIPH SYSCTL_RCGC2_GPIOB

    //*****************************************************************************
    //
    // The GPIO port to check for a forced update. This will be one of the
    // GPIO_PORTx_BASE values, where "x" is replaced with the port name (such as
    // B). The value of "x" should match the value of "x" for
    // FORCED_UPDATE_PERIPH.
    //
    // Depends on: ENABLE_UPDATE_CHECK
    // Exclusive of: None
    // Requries: None
    //
    //*****************************************************************************
    //#define FORCED_UPDATE_PORT GPIO_PORTB_BASE

    //*****************************************************************************
    //
    // The pin to check for a forced update. This is a value between 0 and 7.
    //
    // Depends on: ENABLE_UPDATE_CHECK
    // Exclusive of: None
    // Requries: None
    //
    //*****************************************************************************
    //#define FORCED_UPDATE_PIN 4

    //*****************************************************************************
    //
    // The polarity of the GPIO pin that results in a forced update. This value
    // should be 0 if the pin should be low and 1 if the pin should be high.
    //
    // Depends on: ENABLE_UPDATE_CHECK
    // Exclusive of: None
    // Requries: None
    //
    //*****************************************************************************
    //#define FORCED_UPDATE_POLARITY 0

    //*****************************************************************************
    //
    // This enables a weak pull-up or pull-down for the GPIO pin used in a forced
    // update. Only one of FORCED_UPDATE_WPU or FORCED_UPDATE_WPD should be
    // defined, or neither if a weak pull-up or pull-down is not required.
    //
    // Depends on: ENABLE_UPDATE_CHECK
    // Exclusive of: None
    // Requries: None
    //
    //*****************************************************************************
    //#define FORCED_UPDATE_WPU
    //#define FORCED_UPDATE_WPD

  • Dear Charles,

    thank you for your reply.

    And if I want to make an update of the firmware from remote and asynchronously, what is the procedure?
    I thought that the boot_demo_emac_flash is listening for the "magic packet" and when this packet arrives the application returns the execution to the bootloader.

    The problem is that I want to update the software while it is running. So, the bootloader is not able to check the pin and force the update. Am I missing something?

    Michele
  • Hi Michele,
    Yes, you are correct. If your application is written to transfer control back to the bootloader then it should reprogram. The boot_demo_emac_flash indeed listens to the magic packet. If the magic packet is received then it will transfer control to the bootloader. If you use the wireshark you will see the magic packet comprises 6 bytes of 0xAA followed by the target MAC address repeated 4 times.
  • Hi Charles,

    is the magic packet sent from the LM Flash programmer and from eflash tool as well?

    However, the LM Programmer stays in "Attempting to connect" and I can't see the packet in wireshark. I am looking for the packet with the UDP protocol on port 9.

    Regards,

    Michele
  • Hi Michele,

     It works for me. The magic packet comes from the LM flash programmer. The eflash should be the command line version of the LM flash programmer so it should work similarly even though I never tried the eflash myself. 00:1a:b6:02:c5:a3 is my MAC address. You will have your own MAC address.

     You should be able to see the below on wireshark.

  • Hi Charles,

    I now see the packet. The problem has been solved.

    I have two ethernet cards, let's say card1 and card2. The LM Programmer allows me to choose only the card1, that is the correct one.
    However, the LM programmer has started to work as expected only when I have disabled card2.

    For future reference, I have used Win10 -64 bit.

    Thanks for your clarification and your support.

    Best regards,
    Michele
  • Glad your problem is solved.
  • Hi,
    Is there any utility like eflash or LM flash programmer which supports ethernet based firmware upgrade for linux?
    Regards,
    Apoorv