• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 718 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294NCPDT: how to implement support for tail-tag byte

Christian Sanchez
Prodigy 40 points
Part Number: TM4C1294NCPDT

We have recently switched over to a Micrel switch (KSZ8463) that has 2 external PHY ports, which is connected via the 3rd host port to the TM4C129X PHY. We enabled the Tail-Tag feature on the Micrel switch, which adds a "tail-tag byte" to the end of the frame (before checksum) to indicate which port received the data (for incoming frames), or to indicate which port/s should send the data (for outgoing frames). With tail-tag feature turned-off, everything seems to be working correctly, although obviously the application can't distinguish the receiving port# and just sends the data to both ports (instead of being able to send to 1, 2, or both ports). When the tail-tag feature is turned on, the data received by the application seems to be correct with 1 more data byte, and the tail tag at the right location. Sending out seems to be failing for some reason. The frame is loaded correctly to the Tx descriptor but doesn't seem to go anywhere (nothing appears on Wireshark) although the buffer is released.

Is there an application note or instructions on what MAC config settings should be used?

The original firmware project (from many years ago) was made with the LWIP example included in the TI TIVAWARE example, and modified to work with an external PHY for single and dual-port. Maybe MAC controller doesn't like the extra byte for the control frames?

  • 0
    TI__Guru**** 158815 points

    Hi Christian,

      I have to say this is the first time I'm hearing about the tail-tagging concept. The TM4C EMAC certainly does not have this hardware feature built in. If the extra byte is meant to be added by the software then again this will not be handled automatically by the TivaWare EMAC driver today. Perhaps the question to ask is who is supposed to add the extra byte? If it is to be added by the MCU then is it the application's responsibility to add this extra byte as part of the payload? How are you adding this extra byte today? How will the EMAC know how to calculate the checksum including the extra byte if it is unaware of the extra byte?

     I did some Google research with the following description about tail-tagging. 

     

  • 0 in reply to Charles Tsai
    Prodigy 40 points

    Hi Charles,

    Thanks for the response. In the case of our hardware setup, the Micrel switch adds it to the incoming frame (recalculates the checksum) and sends it over to the TM4C129 PHY. For outgoing frames, the application adds it to the frame before sending it out to the TM4C129 PHY which should then forward it to the Micrel Host port and would then decide whether to send it to Port 1, Port 2 or both ports (most common case). The Micrel in that case would be responsible for stripping out the tail tag and recalculating the checksum.

    I seem to have some luck processing LLDP packets incoming, and sending out the frames (which acts on MAC layer not IP), but other than those, all the other Ethernet functions seem to be down. I'm thinking there might be an issue with the MAC controller on the TM4C129 that is not able to make sense of the extra byte for establishing the PHY communication. Would you think this to be the case if the TM4C129 PHY starts seeing an extra byte?

    Thanks,

    Christian

  • 0 in reply to Christian Sanchez
    TI__Guru**** 158815 points

    Hi Christian,

      The TM4C129 MAC hardware will be unaware of what is a tail-tag extra byte. The MAC will take the payload from the IP layer and encapsulate with the frame header and the checksum. If the extra byte is inserted by the application then it is just part of the application layer payload. In this case, the checksum is calculated including the extra byte. Again, the MAC does not understand what is a tail-tag byte. The MAC will not add or strip it during the checksum calculation. My point is that if you add the extra byte as part of the application payload, how will the MAC know if the payload contain the extra byte or not. To the MAC, it is just bunch of data. 

  • 0
    Guru 92251 points

    Christian Sanchez said:
    Maybe MAC controller doesn't like the extra byte for the control frames?

    How is the application adding the extra byte, and how big is the resulting Ethernet frame?

  • 0 in reply to Chester Gillon
    Prodigy 40 points

    The extra byte is added by the application, so it's just one extra byte at the end of the payload. The resulting frame should then be one byte longer than usual, and then when the Micrel switch processes the tail-tag, it should strip off the tail-tag.

  • 0 in reply to Christian Sanchez
    Guru 92251 points

    Christian Sanchez said:
    I seem to have some luck processing LLDP packets incoming, and sending out the frames (which acts on MAC layer not IP), but other than those, all the other Ethernet functions seem to be down.

    If LLDP Ethertype frames can be transmitted with the tail byte appended by the application, but not other Ethertype frames, it could be the IP payload checksum offload in the MAC causing the problem. From Table 20-2. Enhanced Transmit Descriptor 0 (TDES0) in the datasheet there is the following error bit:

    E.g. if the Checksum Insertion Control is set in the EMAC transmit descriptor to insert a TCP/UDP/ICMP checksum, and if the application appends an extra byte to the end of a frame with a TCP, UDP or ICMP payload then I think the EMAC checksum offload will flag a "IP Payload Error".

    Are you using LWIP or TI-RTOS, and if which version?

    The TM4C Ethernet driver might need to be disable TCP/UDP/ICMP checksum offload to avoid the problem.

  • 0 in reply to Chester Gillon
    Prodigy 40 points

    Hi Chester,

    Yes I had all the checksum checks turned-off, and calculate all the IPv4 checksums on the firmware. It's on LWIP 2.0.2.

    Think I figured out the problem though. The standard ARP response is about 42 bytes, with the tail-tag added in makes it 43. The TM4C129 MAC then pads it to reach the minimum frame length of 64 with the FCS at the end. When the Micrel switch sees the frame, it strips out the tail tag byte which it now believes to be at the end right before the FCS and the added tail-tag by the application is left behind as part of the payload which makes it incorrect. I disabled automatic padding, and had the firmware manually pad the bytes, then add the tail tag before transmitting. This solved the problem and it now works just the way it did if I had tail-tagging turned off.

    Thank you for all the help.

    Christian