TM4C1294NCPDT: TM4C1294NCPDT / LM Flash programmer

Hi,

   A couple of things for you to check.

  - Do you have the correct MAC address entered in the LM flash programmer compared to what the MAC address stored in the USER0/USER1 registers?

  - How did you know that 192.168.1.5 is the correct IP for the client? I will suggest you first run a enet_lwip or enet_io example and obtain the IP address displayed on the terminal window. You will then type that IP address into the LM flash programmer. The reason to do that is because running the enet_lwip will lease the DHCP address for some time. During this time you can use that address for your boot_emac_flash example. If you have already done so, then it is fine. 

  - How long did you wait while it says 'attempting to connect'? Normally the client (MCU) will send a BOOTP request to your server (PC). It will wait for the BOOTP reply from the server. If it does not receive the reply then it will wait for a second before sending the next request. If it does not receive the reply it will wait for 2 seconds and then send the request. This process will continue by waiting 4 seconds, 8 seconds, 16 seconds.... This is the reason I ask how long did you wait. 

  - In the wireshark, did you see the BOOTP request? See something like below.

  - You don't have to pre-program the boot_demo_emac_flash at 0x4000. Please erase it flash entirely and only program via JTAG the boot_emac_flash. Then quickly go to the LM flash programmer and program your boot_demo_emac_flash. Does it make a difference?

Hi Charles,

Thanks for the quick reply.

I check the IP address from the D-Link router DHCP client status as shown below. 1st one is my laptop( in wifi) and 2nd one is the Launchpad.

I cross verified the MAC address with the one in the launchpad printed on backside.   

'attempting to connect'  - I was waiting for more than 5 minutes! 

In wireshark there is no bootp request at all.

I also erased entirely and programmed only boot_emac_flash and then tried programming with ethernet.  Then also same behaviour.

Regards,

Ramesh

Hi,

  If you run enet_io or enet_lwip, do they work? I wanted to make sure it is not your network problem. 

  Can you connect your PC to the router instead of Wifi? Does it make a difference?

  If you run the examples as is then they should work. I have run them many times in the past. So there should be no issues with the examples. 

  when you said you didn't see the BOOTP request? Is it possible that your network setup preventing the wireshark to snoop the network? What if you just run the enet_lwip example, do you see the wireshark capturing any traffic?

I ran enet_lwip.  It works fine.  Screenshot below

Hi Ramesh,

  Thanks for providing the enet_lwip result. So it is working. Can you capture the enet_lwip traffic properly using the wireshark? If yes, can you then recapture the result for the boot_emac_flash? When you said there is no BOOTP request from the client, I wonder what is on the traffic? Can you share?

  Also I asked you to use to connect your PC to the network via the Ethernet cable instead of the Wifi. Can you try and does it make a difference?

Hi Charles,

I tried the following

1. captured wireshark logs with enetlwip and attached (enetlwip.pcapng)

2. Then completely erased and flashed boot_emac_flash alone and tried boot_demo_emac_flash through ethernet. Surprisingly this time it worked. Attaching the screenshot and logs.  However I did not see any bootp transaction in the wireshark logs (emacflash1.pcap and emacflash1.png).

3. Then tried again  to flash boot)demo_emac_flash through ethernet.  It did not work this time.  I had to abort after few minutes (emacflash2.pcap)

4. Then tried again with laptop connected with ethernet cable and wifi switched off  This time also it did not work.(emacflash3.pcap).

Regards,

Ramesh

I am not able to attach wireshark log files.  Any other way I can send the files?

Regards,

Ramesh

Hi Ramesh,

  It is good to see that the example at least works once.

   Here are something for you to check. 

  Once the boot_demo_meac_flash is loaded successfully, the bootloader (boot_emac_flash) will transfer its control to the application (boot_demo_emac_flash). The demo app (the boot_demo_emac_flash.bin program) has code to listen for a magic packet from the TFTP server (the LM flash programmer) indicting that a firmware upgrade is requested and when the packet is received, transfers the control back the boot loader to perform the upgrade. In the LM Flash Program, when you hit the 'Program' button it sends out the magic packet. The magic packet comprises 6 bytes of 0xAA followed by the target MAC address repeated 4 times. When the application receives this magic packet it transfers the control to the bootloader. 

  Please look at the wireshark and see if you see the magic packets getting sent out by the PC. You should see something like below. Please note my MAC address is 00-1A-B6-02-C5-A3. Yours will be different from mine.

Also check the boot_demo_emac_flash.c and swupdate.c files for the below function code. 

The SoftWareUpdateInit is in swupdate.c. This function will setup an UDP connection to receive any magic packet sent from the LM Flash
Programmer. When the magic packet is received the SoftwareUpdateRequestCallback will be called and it will update the flag g_bFirmwareUpdate to true. In the main(), the code is looping waiting for the g_bFirmwareUpdate to be true. When true it will transfer the control to the bootloader by calling the SoftwareUpdateBegin(). 

Hi Charles,

Thanks for the information.  Today I changed the boot_demo_emac_flash to Static ip ( instead of DHCP) and  connected the launchpad directly to the laptop (not through router). Now the program is working consistently. 

However in DHCP case lmflash programmer is sending the magic packet.  But launchpad seems to be not responding back.  screenshot below.

I also noticed the LED blinking is stopped once the program button is pressed in lmflash,   That indicates the control is transferred to bootloader.  However bootloader seems to be not responding

Regards,

Ramesh

Hi Ramesh,

   Can you compare the wireshark output between the working case (using the static address) vs. the non-working case (using DHCP) after the magic packet is sent out by the LM flash programmer?

Wireshark logs where it is working is exported to text file

lmflash1.txt

Wireshark txt file in dhcp and not working.

lmflashdhcp.txt

I have send the wireshark logs for working and not working cases.  Could you compare and let me know the issue

Regards,

Ramesh

Hi,

  Can you select File->Save to save as .pcapng format instead of text file. The text file is extremely hard to read. I assume you never get the application (boot_demo_emac_flash.bin) to load at all using DHCP, correct?

  Another thing I will strongly suggest you do is to try on a different network. For example, If you were having problem with the DHCP in your office network then try the example with your home network and see if you can repeat the same problem. Or try on your office network if your home network didn't work. I just try the example again on a home network as I'm working from home today. Below are the steps I take.

 1. in the LM flash programmer Configuration tab, setup the correct IP address and MAC address. In the Program tab, select the boot_demo_emac_flash.bin (the application FW) as the file to be bootloaded

 2. Load the boot_emac_flash example (the bootloader FM) to the flash using CCS 

 3. Press the reset pin on the board

  4. In the LM flash programmer Program tab, hit the 'Program Button'

  Immediately, I see the boot_demo_emac_flash.bin getting programmed via the Ethernet port. I use the example as is which is using DHCP. Below is my wireshark capture. 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/wireshark.pcapng

Zipped the pcapng files and attaching

lmflash.zip

Hi Charles

.pcapng when uploaded displays error.  I have zipped and attached.  Please have a look.

I have tried in office network and even enet_io itself does not work.  Hence I m trying these in my home network only.  

Regards,

Ramesh

Hi Ramesh,

  I will take a look at your wireshark  capture. 

  In the meantime, I rerun the example in the office network and it works every time. The first time I only have the bootloader (the boot_emac_flash) loaded. I hit the Program button in the LM flash programmer and the application (the boot_demo_emac_flash) will be loaded immediately. After the application is loaded the LED on the board starts to blink. This indicates the application was loaded successfully. Each time I hit the 'Program' button in the LM flash programmer again, i will see the application image reloaded. 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/boot_5F00_emac_5F00_flash.bin

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/boot_5F00_demo_5F00_emac_5F00_flash.bin

  You mentioned that you could see the LED blinking the first time. Once the magic packet is received it seems to jump back to the bootloader but did not continue to reload the application image. I really don't know what is going on as I cannot reproduce your problem from either my office network or home network. What I'm going to ask you try is to use the bin files I attach here. I'm attaching the boot_emac_flash.bin and boot_demo_emac_flash.bin. Try them and see If you are having the same issue. You also mentioned that even the enet_lwip doesn't work in your office network. Therefore, I tend to think there is some network configuration problem on your office network that you will need to resolve with your company IT experts. I really don't know how to help here.

  When you said the after the magic packet is received the bootloader seems to stuck. Look at the Program Counter and see where it is. Is it stuck in the bootloader or in the application? The application starts at 0x4000. You will need to do some debug on your own. 

 Finally, here is the wireshark capture after the magic packet is sent. After the magic packet is received by the MCU, the application image is reloaded again via the TFTP transfer.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/magic_5F00_packet_5F00_boot_5F00_demo_5F00_emac_5F00_flash.pcapng

Hi Charles,

I tried with another router - CISCO Linksys-E4200 and it is working fine consistently.    However it is not working with  dlink dsl-224.  From the wireshork logs I notice the bootp packets are not coming back after magic pkt is send.  

I will try to debug from the controller side next week as well as try to check one more router.

Regards,

Ramesh

Hi Ramesh,

  Glad that you are able to narrow down the issue to the router. If the MCU application received the magic packet and transferred the control back to the bootloader then I don't think the problem is with MCU side. You should be able to debug this easily. If the LED was still blinking after the magic packet was sent then most likely the magic packet was not received.  The reason is that the MCU doesn't know what router is on the network. Once the application transfers control to the bootloader, the bootloader will send out the BOOTP request.  You can also compare the magic packet sent out between the Dlink and Linksys. I will suppose they are the same. If there is any difference then it is worth investigating. I will suggest you spend some time on the router configuration. It seems to me that the magic packet was never received although you see the magic packet on the wireshark capture. Is it possible that the BOOTP server and the MCU are on two different subnets? The magic packet was sent out as a broadcast packet. Is it possible that the dlink router is preventing the broadcast packet due to different subnets? 

Hi Charles,

As soon as the magic packet is send, the LED is off and that indicates the control is transferred to bootloader.  Next step is that the MCU need to send BOOTP request.  However this is not seen in wireshark logs.  Does that mean the router is not supporting bootp request? Is it possible?  I tried to check in router setup and could not find anything.   

Since we have connected mcu in dhcp mode, all devices are in same subnet only.  I have also seen from router status the ip address are always 192.168.1.xx.

Regards,

Ramesh

Hi Ramesh,

  If the LED is turned off then the control is passed to the booloader. I don't understand why the BOOTP was not send out. I cannot repeat the problem. As I said, how will the MCU know what router is out there and decide to send or not send the BOOTP request. I hope you can do some debugging on your side. Since you have a working case using the Linsys router, it will be a bit easier to compare. 

  When you said the IP address is always 192.168.1.xx, you need to make sure it is the same IP address that you entered in the LM flash programmer. I suppose you enter 192.168.1.15 for the client MCU. Is it possible that your DHCP server assign a different IP address other than 192.168.1.15 to the MCU?