TM4C1294NCPDT: TFTP packet problem with TIVA bootloader

Hi Charles

At the moment I have specified a MAC address for the lwip init. I just used the TI one from my eval board. But does the ROM boot loader need to have this in flash? Everything seems to work fine up until the TFTP starts. As far as I can see the LM flash has the correct IP and MAC address. 

Thanks

Jon

    // Set the MAC address
    mac_user0 = 0x0076ff70;
    mac_user1 = 0x00fd6f1d;
    mac_addr[0] = ((mac_user0 >>  0) & 0xff);
    mac_addr[1] = ((mac_user0 >>  8) & 0xff);
    mac_addr[2] = ((mac_user0 >> 16) & 0xff);
    mac_addr[3] = ((mac_user1 >>  0) & 0xff);
    mac_addr[4] = ((mac_user1 >>  8) & 0xff);
    mac_addr[5] = ((mac_user1 >> 16) & 0xff);

    // Init LWIP
    lwIPInit(g_ui32SysClock,
           mac_addr,
           (IP_ADDR_VAL1<<24) | (IP_ADDR_VAL2<<16) | (IP_ADDR_VAL3<<8) | IP_ADDR_VAL4,     // IP
           (SUB_ADDR_VAL1<<24) | (SUB_ADDR_VAL2<<16) | (SUB_ADDR_VAL3<<8) | SUB_ADDR_VAL4, // Subnet
           (GW_ADDR_VAL1<<24) | (GW_ADDR_VAL2<<16) | (GW_ADDR_VAL3<<8) | GW_ADDR_VAL4,     // Gateway
           IPADDR_USE_STATIC);

Charles

I changed the code so that I use the MAC from flash. It didnt seem to make any difference. For some reason I am not getting any ARP packets.

Regards

Jon

Hi Jon,

  I thought you were using the ROM bootloader with the MCU's flash erased. The TM4C129 has the built-in ROM bootloader and I thought that was what you were using. I'm not sure what you are showing in the code. That is your application, not the bootloader. Even if you use the flash-based Ethernet bootloader, the LwIP is not involved. 

  Can you retrieve the MAC address by using the Uniflash tool? If you don't believe the MAC address is the issue, can you run your launchPad in your customer's network? We need to make sure if there is something that is specific to your customer's network or the TFTP server on that work. If possible, can you even try your customer's board on your own office network?

Hi Charles

The code I sent was just the LWIP code that is used initially. I thought this was required to capture the UDP magic packet before the boot loader took over. 

I programmed the MAC using Uniflash and read it back. That is fine.Unfortunately I cant try the board as I am remote debugging it (customer is on the other side of the world). If the boot loader is built into the ROM then I have no reason to think that is not OK. The only thing I can think is that the ARP packets are being stopped on the network. The BOOTP reply from the board has the correct client and server IP address so the board seems to have everything it needs. 

I guess the only other thing would be to try the flash boot loader and see if that behaves the same.

Regards

Jon 

Hi Jon,

Jon Bean1 said:

I thought this was required to capture the UDP magic packet before the boot loader took over. 

The magic packet is sent by the bootP server, not by your board. Your application is supposed to listen for a magic packet telling that a firmware upgrade request is being made and, when this packet is received, transfers control into the boot loader (either the ROM bootloader or the flash bootloader) 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. 

Jon Bean1 said:

Unfortunately I cant try the board as I am remote debugging it (customer is on the other side of the world). If the boot loader is built into the ROM then I have no reason to think that is not OK. The only thing I can think is that the ARP packets are being stopped on the network.

Are you saying both the TFTP sever and the board are at the remote side? The important thing is that the board and the TFTF/BOOTP server are on the same LAN. If the board and the BootP/TFTP server are not on the same network then it will not work. 

Jon Bean1 said:

I programmed the MAC using Uniflash and read it back.

Again, is the the board at the remote site?

Jon, perhaps I was a bit confused in the beginning and may have misunderstood your setup. At first, I thought the flash was completely erased. You were using the build-in ROM bootloader to boot and update the application firmware. Now, I feel that you already have your application in the flash and your application is listening for the magic packet from the BootP server. When the magic packet arrives you will transfer the control from your application to the ROM bootloader. Is this the correct understanding?

Hi Charles

Sorry for the confusion. The setup is that the board and the laptop that the LM flash is running on is at the customer site. They are on the same network.

At the moment I am using the ROM boot loader example project. That sets up the LWIP but maybe that isn't actually required for it to work.

I get the feeling that its something network related. If I look look at the TFTP packet then the MAC of the laptop is empty. The issue seems to be down to the ARP packets that are not there. I guess the board must be sending them as the boot loader is a verified piece of code. I cam only think they are getting dropped somewhere.

Regards

Jon

Hi Jon,

  You might want to check the Boot Reply packet. The Boot Reply from the server is supposed to contain the server's IP address. Once the client obtains the server's address it can send the ARP to find out server's MAC address. Why is the laptop's MAC empty? Perhaps the client didn't get the IP address of the server or just as you stated the ARP didn't finish. In your wireshark capture, the ARP packet is not even shown. 

Hi Charles

As shown below the BOOTP reply from the board seems fine. It has both IP addresses. But as you can also see below the TFTP has no MAC address for the dst in the TFTP packet. On my eval board capture there is the MAC of the pc there. 

Regards

Jon

Hi Jon,

  Earlier you said you programmed the MAC address and read it back fine. If this is the case, the client is supposed to put out the correct MAC address for the DST address.  I really don't know why a 0 address is put out. Please note that not only the MAC address is 0 but also the DST IP address. This is why I ask to check the Boot Reply. Expand the Boot Reply packet and find out what is in that reply packet.

  I'm also curious when you said you programmed the MAC address and read it back fine. What tool did you use to program this "remote" board at your customer's network. Note that the LM flash programmer can only work with ICDI debug probe. What debug probe does your customer use? The Uniflash tool can work with more debug probes such as XDS100 and XDS200.

Hi Charles

The BOOTP reply from the board is shown in my prev message. You can see that the two IP addresses are OK. The TFTP read request from the board has the DST address as 0. I can only think that because the ARP messages are not being seen that the board never gets the MAC address of the pc. It then just uses 0 as the MAC address of the pc as it doesnt have any other address to use.

Regards

Jon

Hi Jon,

  Agree that something is wrong with the ARP. Perhaps you want to ask your customer if he has a launchPad that he can connect to network so you can test if the ARP is working or not.