Problem with ENET

[sarao]

Posted on October 31, 2007 at 14:54

Problem with ENET

[sarao]

Posted on May 17, 2011 at 09:47

STMicro's code from the ENET firmware library u32 ENET_HandleRxPkt ( void * ppkt ) calls the optimized memory copy routine MEMCOPY_L2S_BY4. However, the optimized memory copy's comments state:

Quote:

- N Minimum is 16 bytes

I suggest adding the following check (bold) before calling the MEMCOPY:

Code:

u32 ENET_HandleRxPkt ( void *ppkt) { ... /*check for validity*/ if ( (pDescr != NULL) && (pDescr->dmaAddr) ) { /*Get the size of the packet*/ size = ((pDescr->dmaPackStatus & 0x7ff) - 4); if ( size >= 16 ) // <<< INSERT CODE MEMCOPY_L2S_BY4((u8*)ppkt, RxBuff, size); } ... My system was receiving packets on the network that were less than 16 bytes. When this routine is called with less than 16, the MEMCOPY eventually tries to overwrite RO mem area, causing an exception. This ate a significant amount of time to discover. References: 1.

http://www.st.com/stonline/products/literature/an/12346.pdf

2.

http://www.st.com/stonline/products/literature/um/12376.pdf

[sarao]

Posted on May 17, 2011 at 09:47

I'm doing a test to see what this packet is that is less than 16 bytes.

I have a PC running Windows XP with a network card that is directly connected to my Keil Eval board (MCB-STR9). I'm using WireShark running on the PC with a filter that will hopefully capture this packet. Possibilities: 1. Windows is generating some packet < 16 bytes 2. PHY is delivering some fragment of < 16 bytes

[sarao]

Posted on May 17, 2011 at 09:47

Hey sword.

Thanks for the reply. The problem is that ST's ENET library, as is, will cause an abort exception to occur when it calls the optimized MEMCOPY from the HandleRx method. The code would be more robust if it checked the size before calling that routine. And that is what I am promoting in this thread: add the check (size < 16). Since this eval board is plugged into an ''open'' network, a packet of less than 16 bytes might be received. The other side of this story was that I'm trying to figure out where that small packet is coming from. I currently believe that the PHY is either truncating a larger packet, or generating spurious data. I do not believe the other node on my ''network'' is generating that packet.

[sarao]

Posted on May 17, 2011 at 09:47

Fair enough. 😎

Just to provide a little more information... These ''packets'' are happening pretty infrequently. I've seen them as 10,11,12,13,14, and 15 bytes. I haven't been printing out the bytes, but will be in the next run. Also, WireShark isn't ''seeing'' these, which still leads me to believe this behavior is coming from either the PHY (STE100P) or the microprocessor (STR912F).