You are not logged in.
Hello,
I'm using WARP board v2.2 and reference design 16.1 with csmamac. I have noticed that maccode adds 4 fcs bytes to every packet received from ethernet expect arp packets. For some reason, the code does not remove these fcs bytes before packet is sent via wireless link. Because of this, packets which payload size is near maximum (>maximum-4), are to big and WARP is not able to send these packets.
When I investigated this issue, I found that in temac initialization section in warpmac.c the fcs strip option is disabled. I guess that is the reason cause this problem. I tried to fix the issue by enabling fcs strip option. This change does remove fcs bytes, but packet loss incresed a lot. Then I tried to disable fcs insert option with same results. Only working solution for this issue I have found is just decrease 4 from value of RxPktLength-variable when RxPktEtherType is something else than 0x0806 (ARP). You can find fixed emacRx_handler()-function below.
void emacRx_handler() { unsigned short RxPktLength, RxPktEtherType; int skipDataCallback = 0; int mgmtFrame = 0; void* pktBufPtr; warpnetEthernetPktHeader* thePkt; pktBufPtr = (void *)warpphy_getBuffAddr(controlStruct.pktBuf_emacRx)+NUM_HEADER_BYTES; //Wait for the DMA to be idle warpmac_waitForDMA(); //Set DMA to non-increment source, increment dest addresses XDmaCentral_SetControl(&DmaCentralInst, XDMC_DMACR_DEST_INCR_MASK); //Read the Rx packet length; the packet must be read from the FIFO immediately after this read RxPktLength = XIo_In32(EMAC_FIFO_BaseAddr+XLLF_RLF_OFFSET); //warpmac_setDebugGPIO(0x7); //Transfer the Ethernet frame from the FIFO to the PHY buffer XDmaCentral_Transfer(&DmaCentralInst, (u8 *)(EMAC_FIFO_BaseAddr+XLLF_RDFD_OFFSET), (u8 *)pktBufPtr, RxPktLength); //Extract the EtherType field to determine if this is a management packet thePkt = (warpnetEthernetPktHeader*)(pktBufPtr); RxPktEtherType = thePkt->ethType; #ifdef WARPNET_ETHTYPE_SVR2NODE if (RxPktEtherType == WARPNET_ETHTYPE_SVR2NODE) { //The packet is a WARPnet packet mgmtFrame = 1; skipDataCallback = 1; } #endif #ifdef WARPNET_ETHTYPE_NODE2SVR if (RxPktEtherType == WARPNET_ETHTYPE_NODE2SVR) { //The packet is a WARPnet packet from another node destined to the server; ignore it mgmtFrame = 0; skipDataCallback = 1; } #endif if(mgmtFrame) { //Wait until the DMA transfer is done by checking the Status register warpmac_waitForDMA(); usr_mgmtPkt(RxPktLength, pktBufPtr); } else if( (RxPktEtherType == 0x0806) && ( skipDataCallback == 0) && (controlStruct.dummyPacketMode == 0)) { usr_dataFromNetworkLayer(RxPktLength, pktBufPtr); } else if( (skipDataCallback == 0) && (controlStruct.dummyPacketMode == 0)) { usr_dataFromNetworkLayer(RxPktLength-4, pktBufPtr); } return; }
Offline
Interesting... Thanks for posting this. I think we got a little sloppy in handling the FCS padding when we ported the design from the xps_ethernetlite MAC to the TEMAC. Their support for auto-stripping the checksum bytes is different, and it looks like our code isn't managing it right. We'll investigate and fix it in the next ref design.
Offline
Table 45, page 70 of TEMAC core provides some information on that topic. At least according to this table, if setting length-check to zero, enabling stripping and disabling pass-through, the user code should never see anything of the optional padding and the FCS.
Offline
Thanks, Christian! We'll fix it in the next release.
Offline
But, honestly, I have not tested it since I usually send very small packets. There is probably a bug (core, warpmac, somewhere else) that requires the above modification. It would be good, if mato/HT or someone else could test it in their scenario.
Offline