TM4C129ENCPDT: Remote programming over Ethernet using LM Flash Programmer

Hi,

Sahil said:

• 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. 

Sahil said:

• 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,

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

Hi Sahil,

Sahil said:

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

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);

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

Sahil said:

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. 

Sahil said:

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

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

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