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.

TM4C129ENCPDT: Remote programming over Ethernet using LM Flash Programmer

Part Number: TM4C129ENCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Hi,

We have bunch of devices installed over local network. We have used the remote programming approach using LM Flash Programmer and it works fine. However one thing we have noticed, the programmer would take 5-8 minutes to discover the remote device once it finds the remote device the programming takes less than a minute. We have couple of switches in the network. However we have also tried a small Local network where only the TM4C MicroController was connected but the LM Flash programmer would still take around 4-5 minutes to discover it.

I have following question;

  1. Is this a known issue ? Any idea what could be causing it ? Alternatively, how can I speed up to discover the remote device faster
  2. Since we have bunch of devices installed on the network, it is very tedious and manual work to enter MAC address for each device. Is there any way I write a python script which would hold bunch of MAC addresses that will be fed to the LM Flash Programmer and the programmer will start programming the device one after the other ?
  3. Is there Linux version (Redhat) for LM Flash Programmer ?

Thanks

  • Hi,

    • Is this a known issue ? Any idea what could be causing it ? Alternatively, how can I speed up to discover the remote device faster

    I have not come across such a reporting on the forum where it would take 5-8 minutes to discover the remote device.

    Have you had a chance to run the stock boot_emac_flash and boot_demo_emac_flash?

    Can you repeat the same long discovery time?

    I just ran the example as is. After the boot_demo_emac_flash is loaded the first time, the application starts to run. Each time in LM flash programmer I hit the program button, it takes just a few seconds to update the application again and again. The example application boot_demo_emac_flash will wait for a magic packet from the TFTP server. When the magic packet is received, it will jump to the bootloader to reload the application. 

    • Since we have bunch of devices installed on the network, it is very tedious and manual work to enter MAC address for each device. Is there any way I write a python script which would hold bunch of MAC addresses that will be fed to the LM Flash Programmer and the programmer will start programming the device one after the other ?
    • Is there Linux version (Redhat) for LM Flash Programmer ?

    There is a command line version of LM flash programmer for the Ethernet download. The executable is in C:\ti\TivaWare_C_Series-2.2.0.295\tools\bin\eflash.exe. The source code is in C:\ti\TivaWare_C_Series-2.2.0.295\tools\eflash directory. You can port it to Linux. There is no Linux version for LM flash programmer, only Windows. 

    There was a known issue in LM flash programmer such that if there are two NIC on your PC, the LM programmer may incorrectly send the magic packet to the wrong NIC and not to the NIC connected to the same network as your client device. I don't think it is the problem you are facing now but wanted to bring it to your attention incase you run into the same issue. 

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/675608/tm4c1294kcpdt-lmflash-ethernet-update-bug---magic-packet-sent-on-wrong-interface

  • Hi, Can you please share the document, you have the screen shot for Ethernet Flash Downloader. As I need to look into the details to convert the source code to run on Linux machine. Thanks

  • The user's guide that describes the eflash.exe can be found C:\ti\TivaWare_C_Series-2.2.0.295\docs\SW-TM4C-TOOLS-UG-2.2.0.295.pdf

  • Hi 

    I found the issue was related to firewall on my PC. I am able to remotely program the device however, the device would not reset on its on and I have to power cycle after programing. 

    Here is the code section that triggers the remote programming event.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    HWREG(NVIC_DIS0) = 0xFFFFFFFF;
    HWREG(NVIC_DIS1) = 0xFFFFFFFF;
    HWREG(NVIC_DIS2) = 0xFFFFFFFF;
    HWREG(NVIC_DIS3) = 0xFFFFFFFF;
    HWREG(NVIC_DIS4) = 0xFFFFFFFF;
    ROM_SysTickIntDisable();
    ROM_SysTickDisable();
    SysCtlDelay(5000);
    ROM_UpdateEMAC(sys_clock);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Any idea what could be wrong ?

    Also please share any reference project that I can compare my code to in case I have some difference in the vector table etc ?

    Thanks

  • Hi,

      I'm currently on vacation. I will look into your question when I come back. Sorry for the delayed response. 

  • Hi,

    Did you have any chance looking into the issue ?

  • On the same page. We are having one additional issue, some of the devices would stuck once it goes into bootloader, the program progress (the program prints progress in percentage in windows power shell terminal) will stuck at zero. When we kill the program by Ctr+C. The remote device gets lost and will not boot-up. To recover the device, we have to program it locally using the JTAG port.

  • Hi Sahil,

    however, the device would not reset on its on and I have to power cycle after programing. 

    Here is the code section that triggers the remote programming event.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    HWREG(NVIC_DIS0) = 0xFFFFFFFF;
    HWREG(NVIC_DIS1) = 0xFFFFFFFF;
    HWREG(NVIC_DIS2) = 0xFFFFFFFF;
    HWREG(NVIC_DIS3) = 0xFFFFFFFF;
    HWREG(NVIC_DIS4) = 0xFFFFFFFF;
    ROM_SysTickIntDisable();
    ROM_SysTickDisable();
    SysCtlDelay(5000);
    ROM_UpdateEMAC(sys_clock);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    HWREG(NVIC_DIS0) = 0xFFFFFFFF;
    HWREG(NVIC_DIS1) = 0xFFFFFFFF;
    HWREG(NVIC_DIS2) = 0xFFFFFFFF;
    HWREG(NVIC_DIS3) = 0xFFFFFFFF;
    HWREG(NVIC_DIS4) = 0xFFFFFFFF;
    ROM_SysTickIntDisable();
    ROM_SysTickDisable();
    SysCtlDelay(5000);
    ROM_UpdateEMAC(sys_clock);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Any idea what could be wrong ?

     While I don't have a good answer to your problem, I find this post to be maybe helpful. This post seems to have similar issue although it is calling ROM_UpdateUART() instead of ROM_UpdateEMAC(). This post mentions that after loading the new firmware, they must do a manual reset to get it started properly. I think it is worth trying the suggested solution to see if it makes a difference to your project. Go to the end of the post where John replaced the HWREG(NVIC_DIS0) = 0xffffffff and HWREG(NVIC_DIS1) = 0xffffffff with individual peripheral interrupt disables. 

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1025914/tm4c123gh6pm-invoke-rom_updateuart-programmatically

  • Thanks Charles. The link seems helpful but as I mentioned our higher priority issue is the devices stuck and we loose the device altogether. We have to bring the device back to the lab and program it via JTAG in order to recover it. Please keep in mind this is happening with almost every 3rd device we program. 

  • Hi,

      When you said it is stuck, do you know where the processor is stuck at? Earlier you seem to suggest that the problem is that the device will not reset after bootloading and you would need to manually reset the device but now it is stuck which is a very different behavior. What was changed? 

      In any case, please refer to the post I just referred. That post mentioned it is getting an exception before calling the ROM_UpdateXXX which is in a sense getting stuck in the hard fault handler. I wonder if this is what you are seeing as well. 

  • Let me follow up  on the post you shared and see if it is related and fix the problem.

    I will get back to you. Thanks and you have a great day.

  • Hi Charles,

    I followed the link and made changes accordingly and it resolved the problem where the processor would stuck and we would loose the device and we had to use JTAG to reprogram the device locally. Now this problem is resolved.

    However, I am still struggling with earlier problem i.e. The Device after remote programming, will not reset itself and we have to power cycle the device. Once we power cycle it runs the newly programmed firmware fine.

    I tried to debug and see once the device is successfully programmed over ethernet where exactly it hangs.

    I see it would hang up on 

    Fullscreen
    1
    memcpy(outbuf, (const unsigned char*)count_p, count);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    which is in copy_decompress_non.c file. You can also see the Disassembly view and the Core registers states in the picture bellow;

    Any idea or hint ?

    Thanks.

  • I followed the link and made changes accordingly and it resolved the problem where the processor would stuck and we would loose the device and we had to use JTAG to reprogram the device locally. Now this problem is resolved.

    Glad some progress is made. 

    However, I am still struggling with earlier problem i.e. The Device after remote programming, will not reset itself and we have to power cycle the device. Once we power cycle it runs the newly programmed firmware fine.

    I tried to debug and see once the device is successfully programmed over ethernet where exactly it hangs.

    I see it would hang up on 

    Fullscreen
    1
    memcpy(outbuf, (const unsigned char*)count_p, count);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    Fullscreen
    1
    memcpy(outbuf, (const unsigned char*)count_p, count);
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    which is in copy_decompress_non.c file. You can also see the Disassembly view and the Core registers states in the picture bellow;

    I'm not sure why it is stuck in the device startup at _TI_decompress_none.

    Do you have -llibc.a in your link library?

    If you run the the TivaWare example C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_emac_rom, will you see the sane problem? This TivaWare example calls ROM_UpdateEMAC to jump to the ROM bootloader. If the example works without getting stuck, can you compare with your application and startup file and build configuration?

    If you run your application on a LaunchPad, do you see the same problem?

    Not sure if this post will be helpful or not about _TI_decompress_none.

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1012140/rm57l843-__ti_decompress_lzss-and-__ti_decompress_none-functions?ReplyFilter=Answers&ReplySortBy=Answers&ReplySortOrder=Descending

  • Hi Charles,

    I have the libc.a included already. However I did see some differences in the linker configuration of my project vs boot_demo_emac_rom. I am not exactly sure whatchange has exactly fixed the problem but I tried to match the linker configuration as close as possible to the demo project and it made it to work.

    Now, I can remotely program and it would successfully reset as well.

    Thanks for your help and you have a wonderful weekend.

    Regards,

    Sahil