Original question:
TM4C1294NCPDT: LM Flash Programmer 16.13 download using Ethernet fail
I am using the boot_emac_flash project with my own application. I load boot_emac_flash at 0x0 and my application is loaded at 0x4000. A software command in my application calls a routine that duplicates the code in the boot_demo_emac_flash file and I have traced it down to where it calls the bootloader in function SoftwareUpdateBegin. What I am seeing in Wireshark is a constant UDP packet of 72 bytes that contains the MAC address. The bootloader is in the UpdateBOOTP main application loop.
Hi Robert,
Did the original example with both the boot_emac_flash (as the bootloader) and the boot_demo_emac_flash (as the application firmware) work?
If the bootloader is executing the UpdateBOOTP then it should send out the BOOTP request to the server. What did you do from the server side? If you are using the LM flash programmer did you go to the Program tab and specify your application file and then hit the Program button? See below.
Can you show your wireshark capture?
Please first run the original example with the boot_demo_emac_flash application? You should see something like below?
Hi Robert,
I want to know how you setup the server side. I assume you have done do but just wanted to make sure.
1. Erase your flash completely.
2. Program the bootloader (boot_emac_flash) into the flash via the JTAG. The bootloader will be programmed starting at 0x0. Run the program.
3. In LM flash programmer specify the client IP address and the MAC address. You should get the IP address in the terminal window after you run step 2.
4. Specify the boot_demo_emac_flash.bin and hit the Program button.
It may take a while to see the actual TFTP transfer. The reason is that immediately after you run the bootloader in step 2 the client is sending the BOOTP request. However, you have yet to click the Program button in step 4. If the client does not receive the reply from the server it will wait for 1 second before it sends the next BOOTP request. If no response from the server further then it will then 2 seconds, 4, 8, 16, 32.... Therefore, the longer you wait to hit the Program button the longer (i.e. waiting 32 seconds) before the client sends the next BOOTP request. Once you hit the Program button the TFTP should start. If this is not the problem you are seeing then it will be something else. The example always work. If the example doesn't work at your side then it is not the software side of issue on the client side.
Please follow two steps to attach the image.
Hi Robert,
Sorry, my bad. I need to add step 0 too.
0. Run either enet_lwip or enet_io example to acquire the IP address from your DHCP server. See below screenshot. The reason to first run this example is to simply acquire an IP address. The bootloader is meant to be very compact in size using the BOOTP protocol. However, the BOOTP is static in nature, unlike the DHCP which provides dynamic IP address to the client upon request. Normally your DHCP will lease an IP address to your client (the MCU) for a certain time frame, may be hours or a day. Right after you acquire the IP address by running the enet_lwip the IP address will still be valid for a while. This is the IP address you want to enter in the LM flash programmer. If you are using the launchpad then in the back of the board, there is a sticker that shows the MAC address. The LM flash programmer is acting as the BOOTP and TFTP server. It must have the association between the IP address and the MAC address pre-recorded in its system. Please note that you must have the correct IP address and MAC address entered in the LM flash programmer. Without them, the sever cannot accept the BOOTP request from the client.
Robert,
Ok. So there is nothing wrong with the ARP packet. That is a good starting point.
I just repeated the same test on my Evaluation Board. Earlier I was testing on a LaunchPad. It is still working for me in the Evaluation board. Please see below images. Please note my client target address and MAC address will be different from yours. As a matter of fact your client address should be 172.16.2.137 and 00-1A-B6-02-96-78 and I think you entered them correctly into the LM flash programmer.
You should see 55704 bytes transferred after it is done.
I really don't know why it is not working on your side. Your client seems to send out the BOOTP packets. However, you said it got stuck in the ARP. When you run the enet_lwip your PC is able reply its MAC address but not when you run the bootloader. This is where I'm lost too.
Can you rerun the example? Now please do what I have been telling earlier. I repeat, please do NOT load the boot_demo_emac_flash via JTAG. You have been doing that in the past. Just load the boot_emac_flash (the bootloader) into the flash and run it. On the server side (the LM flash programmer), enter the IP and MAC address which you have done already. You can just go to the Program tab and hit the program button. Perhaps you want to hit the program button after you see the BOOTP sent out by the client. Let's see if you can get this work before you venture into updating new application firmware when the flash already has an running application firmware.
