• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 822 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C129 Strange BOOTP packet seen

Simon Bird
Prodigy 230 points

I am using a TM4C129 on a TI Launchpad with Tivaware 2.1.1.71. I am trying to perform a bootload over ethernet with the boot triger being via a GPIO (PE3). Most of the time, the bootload works. About 20% of the time, I see a strange BOOTP packet being sent from the Launchpad to the Windows host. I see this strange packet in the packet sniffer that I am using as well as in the Windows host program itself. This is all using custom code on the Windows side as well as for the TI app (but note that the bootloader here is the TI supplied flash bootloader).

When I see the strange packet, it starts with the expected

0x01 0x01 0x06

which I believe indicates that this is a BOOTP request but the rest of the data does not match the expected pattern. In particular, I do not see the data representing the string "tiva" or "stellaris" for the server name. Instead I see a string of 0's so the Windows host code does not recognize the BOOTP request and therefore does not send a valid reply to allow the board to continue to the TFTP portion. When I see this packet the data is something like (obviously this is for a given transaction ID; values are in HEX; xx values are an IP address):

01 01 06 00 34 DB A6 C2 00 00 00 00 xx xx xx xx 00 00 00 00 00 00 00 00 00 00 00 00 20 47 47 BB AA B8 00 00....etc... all 00 after this

The valid data looks something like

01 01 06  00 D7 7C EE 91 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1A B6 00 64 00 00 00 00 00 00 00 00 00 74 69 76 61 00 00 ... etc

The other strange thing is that the packet sniffer refers to the first data listed above as DHCP rather than BOOTP (and maybe it is DHCP. I am not sure about that) but I find it strange that the 01 01 06 byte pattern is there.

I am wondering if anyone else has seen this and if so, is there a workaround other than to have the Windows host keep trying to receive a BOOTP packet. If I do that as a workaround, then on the second or third receive attempt the host software does receive a valid BOOT packet and I am able to continue and exercise the TFTP code, which completes correctly. 

So, is this expected behavior or is there something that I should be looking at to prevent this from happening? Any buffers that should be flushed etc? 

  • 0
    TI__Mastermind 22580 points
    Hello Simon,

    What bootlaoder are you using - ROM-based or Flash-based?

    Sai
  • 0 in reply to Sai Reddy
    Prodigy 230 points
    I was under the impression that this is the flash bootloader
    Simon
  • 0 in reply to Simon Bird
    Prodigy 230 points
    The App start address is 0x4000 in bl_config.h, which I believe means that this is the flash based bootloader.
    Simon
  • 0
    TI__Mastermind 22580 points
    Hello Simon,

    The first two bytes of "0x01 0x01 0x06" indicate that the packet is a Bootp Request and the Hardware used is Ethernet.

    What I find surprising is that the two byte field after "Transaction ID" is 0. This field should to populated with time since the board started the Bootp process. This field will contain 0 if it is a DHCP message (maybe that's the reason the packet sniffer refers to it as a DHCP packet). The bootloader does not send a DHCP packet.

    Are you sure that the packet specified above, originates from a TM4C129 board running the bootloader? Could you take a wireshark log, with the error packet and the transaction before and after the Bootp request? When you do that please include the IP address and MAC address of the PC and the LaunchPad. Feel free to PM me, if you don't want to post the log file here.

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Prodigy 230 points

    Hi,

    Ok, I took a look at the log again and I think I see what has happened. It looks like you were correct, the "strange" packet was not from the TM4C129.

    I was running the test on a PC that had 2 NICs, one for the TM4C129, the other being the corporate LAN. Looks like something on the LAN sent the strange packet, which would explain why it did not contain the expect "tiva" server. I repeated the test with the LAN disconnected and did not see the issue. Looks like I need to tidy up my host PC software so that the application does not treat data received from the LAN as a possible BOOTP packet. Easy enough to do as the TM4C129 NIC is using a static IP address.  

  • 0 in reply to Simon Bird
    TI__Mastermind 22580 points
    Hello Simon,

    Glad you have a solution to address the issue.

    Even if TM4C129 is not using static IP address, I believe you could do something similar to what "LM Flash Programmer" does. With "LM Flash Programmer", the user enters the MAC address and IP address of the board, which allows the "LM Flash Programmer" to filter the packets.

    Thanks,
    Sai
  • 0 in reply to Sai Reddy
    Prodigy 230 points
    Yes, that would work too.
    Thanks

    Simon