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.

Tx Crc Offload

Other Parts Discussed in Thread: TM4C129ENCPDT, EK-TM4C129EXL, AM3352

Hi,

I have the Ethernet port working (Tx and Rx). All frames are correct except for the ping reply message where wireshark is reporting a Crc error.

emacConfig.c
	// Configure for use with the internal PHY.
	EMACPHYConfigSet(	EMAC0_BASE,
						EMAC_PHY_TYPE_INTERNAL	  |
						EMAC_PHY_INT_MDIX_EN	  |
						EMAC_PHY_AN_100B_T_FULL_DUPLEX);

	// Initialize the MAC and set the DMA mode.
	EMACReset(EMAC0_BASE);   // Reset the MAC.
	EMACInit(EMAC0_BASE,gSysCtlClock,
						EMAC_BCONFIG_MIXED_BURST |
						EMAC_BCONFIG_PRIORITY_FIXED,
						4,
						4,
						0);
	EMACConfigSet(EMAC0_BASE,
					  (	EMAC_CONFIG_FULL_DUPLEX		    | 	//operate in full- or half-duplex mode
						EMAC_CONFIG_CHECKSUM_OFFLOAD	|	//enables header checksum checking
						EMAC_CONFIG_7BYTE_PREAMBLE	    |	//number of bytes of preamble added
															//to the beginning of every transmitted
															//frame
						EMAC_CONFIG_IF_GAP_96BITS	    |	//interframe gap between transmitted
															//frames
						EMAC_CONFIG_USE_MACADDR0		|	//which MAC address is used during
															//insertion or replacement for all
															//transmitted frames
						EMAC_CONFIG_SA_FROM_DESCRIPTOR  |	//Control over insertion or replacement
															//of the source address in all
															//transmitted frames
						EMAC_CONFIG_BO_LIMIT_1024	    ),	//The back-off limit determines the
															//range of the random time that the MAC
															//delays after a collision and before
															//attempting to retransmit a frame.
					  (	EMAC_MODE_RX_STORE_FORWARD	    |	//receive DMA to read frames from
															//the FIFO only after the complete
															//frame has been written to it.
															//If this mode is enabled, the
															//receive threshold is ignored.
						EMAC_MODE_TX_STORE_FORWARD	    |	//start transmitting a frame only
															//after the whole frame has been
															//written to the transmit FIFO.
															//If this mode is enabled, the
															//transmit threshold is ignored.
						EMAC_MODE_TX_THRESHOLD_64_BYTES |	//transmit FIFO threshold
						EMAC_MODE_RX_THRESHOLD_64_BYTES ),	//receive FIFO threshold
						0);

    for(ui32Loop = 0; ui32Loop < NUM_TX_DESCRIPTORS; ui32Loop++)
    {
		//DES0
		//control and status bits
		//Bit 31 is the ``OWN'' bit which, when set, indicates
		//that the hardware has control of the descriptor.
        g_psTxDescriptor[ui32Loop].ui32CtrlStatus =(
							DES0_TX_CTRL_LAST_SEG  |
							DES0_TX_CTRL_FIRST_SEG |
							DES0_TX_CTRL_INTERRUPT | 	//send interrupt on completion
							DES0_TX_CTRL_CHAINED);		//DES3 contains next descriptor address
//							DES0_TX_CTRL_IP_ALL_CKHSUMS);//insert CRC
//							DES0_TX_CTRL_REPLACE_CRC);	//updated and replace CRC
//							DES0_TX_CTRL_NO_CHKSUM);	//don't insert CRC

        //DES1
		//size of the buffer attached to the descriptor and various control bits
        g_psTxDescriptor[ui32Loop].ui32Count = (
							 DES1_TX_CTRL_SADDR_NONE   |
							(TX_BUFFER_SIZE << DES1_TX_CTRL_BUFF1_SIZE_S));
		//DES2
		//pointer to the buffer containing the data to transmit
        g_psTxDescriptor[ui32Loop].pvBuffer1  = g_pui8TxBuffer;
		//DES3
		//set the next descriptor address
        g_psTxDescriptor[ui32Loop].DES3.pLink =
							(ui32Loop == (NUM_TX_DESCRIPTORS - 1)) ?
							g_psTxDescriptor : &g_psTxDescriptor[ui32Loop + 1];
    }

Can anyone tell me what could be the problem?

Khaled.

  • Hello Khaled,

    Have you configured the MAC to disable CRC insertion? If so, can you try with the option "DES0_TX_CTRL_IP_ALL_CKHSUMS" enabled?

    Thanks,
    Sai
  • Hi Sai,

    I tried DES0_TX_CTRL_IP_ALL_CKHSUMS but the ARP reply message still don't have the last 4 CRC bytes.

    I'm not sure if there is some combination of flags that I should enable in order for the CRC to be inserted. In my original e-mail, I sent the configuration/flags that I'm using.

    struct uip_eth_hdr {
      struct uip_eth_addr dest;
      struct uip_eth_addr src;
      u16_t type;
    };

    struct arp_hdr {
        struct uip_eth_hdr ethhdr;       //ethernet header

        uint16_t hwtype;                //Hardware type
        uint16_t protocol;              //Protocol type
        uint8_t  hwlen;                 //Hardware address length
        uint8_t  protolen;              //Protocol address length
        uint16_t opcode;                //ARP opcode
        struct uip_eth_addr shwaddr;    //Sender hardware address
        uint16_t sipaddr[2];            //Sender protocol address
        struct uip_eth_addr dhwaddr;    //Target hardware address
        uint16_t dipaddr[2];            //Target protocol address
    };

    In my applicaiton, I filled the ARP header (see below) and send it the Etherent Tx descriptor. As you can see, there is no CRC field in that structure. I was under the impression that the Phy/Mac layer will automatically add the CRC.

    Khaled.

  • Hi Sai,
    I'm still not able to get that CRC error to go away. Do you have a different proposal? Would you like me to send you more codes or even a project?
    Khaled.
  • Hello khaled,

    Sorry for the delay in response. Are you sure that this error (incorrect CRC being inserted) is only with Ping packet? If you send non-Ping packets, is the correct CRC getting appended automatically. If so, can you send me your project?

    Thanks,
    Sai
  • DSP1000_Phase2M4 - TI Ping CRC.zipHere is the project.

    I cleaned most of the non-relevant code and it should be self contained.

    The project is located in Cortex/Project/adaptivebrd.uvprojx

    The modem IP address is 169.254.15.5

    If you ping 169.254.15.5 you will receive a reply with the CRC error.

    Khaled.

  • Sai,
    Did you get the chance to run my code and replicate the problem?
    Khaled.
  • Hello Khaled

    I would be investigating the issue further. Have you been able to make any progress or the issue is still there?
  • khaled saab said:
    All frames are correct except for the ping reply message where wireshark is reporting a Crc error.

    Is the ping actually successful?

    I found a similar thread Ethernet Frame Check Sequence Incorrect which suggests that Wireshark can falsely report an invalid CRC (Frame check sequence) even though the actual received CRC was valid. And if the actual received CRC was invalid the Ethernet card would have dropped the Ethernet frame and so Wireshark wouldn't be able to capture the Ethernet frame.

  • Hi Amit,

    No progress.

  • Chester,
    Yes the pings are successful. You could be right. I have no way to confirm it.
    Khaled.
  • Hello Khaled,

    OK. I will be working on this next.
  • khaled saab said:
    Yes the pings are successful. You could be right. I have no way to confirm it.

    Is the TM4C129ENCPDT connected directly to the PC running Wireshark or via an Ethernet switch?

    If connected directly to the PC can you see if any FCS errors are being reported by the PC network adapter.

    If connected via an Ethernet switch, if the Ethernet switch has a management interface can you check if the Ethernet switch has reported any FCS errors.

    I tried to investigate the problem, but was unable to since on my Windows PC with an Intel 82579V Gigabit Network Connection:

    a) winpcap is not passing the FCS in the Ethernet frames to Wireshark, and so Wireshark is unable to check the FCS.

    b) I can't get Windows to display the error counts for the network connection, even after trying to edit the registry to set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\Connections\StatMon\ShowLanErrors to 1.

  • Hello Chester,

    I am also seeing the same issue. The next thing I am trying to do is to setup a scope to capture a basic frame to see if CRC is there or not.
  • khaled saab said:
    The project is located in Cortex/Project/adaptivebrd.uvprojx

    The modem IP address is 169.254.15.5

    If you ping 169.254.15.5 you will receive a reply with the CRC error.

    I built that project with uVision V5.21.1.0 and loaded it into a EK-TM4C129EXL. When I ping 169.254.15.5 Wireshark is reporting a FCS error on the ARP reply and the ping replies:

    I don't believe the bad FCS reported by Wireshark is real since:

    a) When the above Wireshark captures were made the CPSW Ethernet switch in an AM3352 was between the EK-TM4C129EXL Ethernet port and the PC performing the pings. The CPSW Ethernet switch statistics didn't report any CRC errors.

    b) If I perform a ping when the tcpEcho_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT example is running, then no bad FCS is reported by Wireshark. Also with the tcpEcho_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT example Wireshark isn't reporting the FCS value and the length reported by Wireshark is 4 bytes less than for the Cortex/Project/adaptivebrd.uvprojx project:

    With the Cortex/Project/adaptivebrd.uvprojx project I suspect what is happening is that:

    a) The software adds 4 bytes of padding, to reserve space for the FCS.

    b) The TM4C129 EMAC adds a valid FCS after the padding.

    c) Wireshark sees the 4 bytes of padding as a FCS, for which a bad FCS is incorrectly reported.

  • Hello Chester

    So it implies that the setting to add the FCS is not the in the position but after the padding. Is that right?
  • Amit Ashara said:
    So it implies that the setting to add the FCS is not the in the position but after the padding. Is that right?

    That is my current theory, and am currently looking at the code to try and prove it.

  • khaled saab said:
    I cleaned most of the non-relevant code and it should be self contained.

    The project is located in Cortex/Project/adaptivebrd.uvprojx

    Am I correct in thinking that the project was originally created for the now obsolete LM3S9B96, and the problem occurred when the project was ported to a TM4C129ENCPDT?

    From looking at the code in the Ethernet_Driver.c source file the EthernetProcessIp() and EthernetProcessARP() functions set the length of the reply packets to be the same as the length of the received requests.

    The default configuration of the TM4C129 EMAC driver is to pass the received FCS to the application, and the FCS is included in the length of the frame.

    As an experiment I modified the Ethernet_Init() function to add the EMAC_CONFIG_STRIP_CRC option to the ui32Config parameter of the EMACConfigSet() call, which strips the last 4 bytes (frame check sequence) from all Ether type frames before forwarding the frames to the application.

    With this modification Wireshark is no longer reporting any FCS in the ARP and ping replies, and the length reported by Wireshark has reduced by 4 bytes compared to the original code:

    I haven't analyzed if the addition of the EMAC_CONFIG_STRIP_CRC option will break the other Ethernet handling code in the project.

    Does the application need to receive the FCS in received Ethernet frames?

  • Chester,

    Chester Gillon

    Am I correct in thinking that the project was originally created for the now obsolete LM3S9B96, and the problem occurred when the project was ported to a TM4C129ENCPDT?

    Yes you are correct. the project was originally build for LM3S9B96 and then ported to the TM4C129ENCPDT.

    Chester Gillon

    From looking at the code in the Ethernet_Driver.c source file the EthernetProcessIp() and EthernetProcessARP() functions set the length of the reply packets to be the same as the length of the received requests.

    Yes the length of the reply packet is set to be the same as the length of the received request.

    Chester Gillon

    Does the application need to receive the FCS in received Ethernet frames?

    I'm not that familiar with ARP and its different flavors, but No, the application don't need to receive the FCS. My understanding is as follow: If the PC sends an FCS, I sould reply with one. What ever the Host PC sends, I should be able to process and reply to.

    Khaled.

  • khaled saab said:
    Yes you are correct. the project was originally build for LM3S9B96 and then ported to the TM4C129ENCPDT.

    I haven't checked StellarisWare, but think the issue is that StellarisWare didn't pass the FCS in received Ethernet frames to the application but by default TivaWare is passing the FCS in received Ethernet frames to the application.

    Were you able to try my suggested change of adding the EMAC_CONFIG_STRIP_CRC option to the EMACConfigSet() call to see if that prevents Wireshark from reporting CRC errors on the ping replies, as well as allowing your other Ethernet communication to continue to work?

  • Chester,
    Yes I did add the EMAC_CONFIG_STRIP_CRC and indeed, the incorrect CRC message is gone.
    As far as I can tell, all other commands are working :-)

    But, wont this command remove the CRC for all frames? and what if the CRC is requested by the user? why the EMAC_CONFIG_CHECKSUM_OFFLOAD is not working? Bottom line I prefer to have the CRC enabled.

    thanks for identifying the problem.
    Khaled.
  • Hi Chester,

    Just to have a closer on this issue: what code modification can I do in order to still send the CRC with the ARP messages or any other Ethernet messages? Can I still off load the CRC handling to the Ethernet driver?

    Khaled.

  • khaled saab said:
    what code modification can I do in order to still send the CRC with the ARP messages or any other Ethernet messages? Can I still off load the CRC handling to the Ethernet driver?

    As far as I can your original code was offloading the CRC handling to the Ethernet driver.

    The problem was that the application was adding four bytes of padding to the data payload of the Ethernet frames, after which the Ethernet hardware added a valid CRC.

    The issue was that Wireshark saw the four bytes of padding as the CRC, and then Wireshark spuriously reported the four bytes of padding as an invalid CRC. This is because it is PC network card specific about if the actual received CRC gets passed to Wireshark - and four bytes of padding is sufficient to make Wireshark think the receive CRC has been passed.

    My suggestion to add the  EMAC_CONFIG_STRIP_CRC option prevented the addition of four bytes of padding, which then avoided the spurious warning from Wireshark about the invalid CRC.

  • Chester,

    I'm not at easy activating the EMAC_CONFIG_STRIP_CRC option since it might strip the CRC from other packets (UDP, TCP...)

    Tried to remove the 4 padding bytes by reducing the size of the returned ARP reply message with EMAC_CONFIG_STRIP_CRC option disabled and it did not work.

    So my question: any way to not use the EMAC_CONFIG_STRIP_CRC option and fix my ARP reply message?

    Khaled