Tool/software: TI-RTOS
Hello,
I am using AM37x with LAN9221 .
We encounter issue in which in receiving packets,
in some scenarios, the detected packets omit the first 4 bytes,
for example, instead of getting good packet:
0a 1b 3c 4d 5e 6f 50 7b 9d a6 4c 39 08 06 00 01
08 00 06 04 00 01 50 7b 9d a6 4c 39 c0 a8 01 6e
0a 1b 3c 4d 5e 6f c0 a8 01 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 23 51 d6 1c
We get instead the following bad packet which omitted the first 4 bytes:
5e 6f 50 7b 9d a6 4c 39 08 06 00 01 08 00 06 04
00 01 50 7b 9d a6 4c 39 c0 a8 01 6e 0a 1b 3c 4d
5e 6f c0 a8 01 64 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 23 51 d6 1c 00 00 00 00
As you can see, the first 4 octets in the destination mac address (from 6 octet mac address),
are missing.
We use the same driver as u-boot, as you can see below.
If there is any idea what can cause such effect, can you please advise us ?
This is highly safety product, and we are not sure how to deal with this issue.
The test is a udp ping-pong between pc and target:PC send a udp buffer to target then wait for received packets and verify it is the same as the packet it send, and then continue to send next buffer,Target wait for buffer from PC, and on receiving buffer , send the exact content back to PC, i.e. it is complete synchronized test, in which send is done only after receiving has finished (in both sides).
The target is based on TI's chip with LAN9221 , as ethernet controller. The routine (from u-boot code) for recieving buffer is:
int ETH_rx(void)
{
u32 *data ; //(u32 *)&g_NetRxPackets[0];
u32 pktlen, tmplen;
u32 status;
int ret = OK;
if ((ETH_reg_read( RX_FIFO_INF) & RX_FIFO_INF_RXSUSED) >> 16) {
status = ETH_reg_read( RX_STATUS_FIFO);
pktlen = (status & RX_STS_PKT_LEN) >> 16;
ETH_reg_write( RX_CFG, 0u);
tmplen = (pktlen + 2u+ 3u) / 4u;
if (tmplen >= EMAC_PACKET_MAX_SIZE)
{
ret = ERROR;
}
else
{
data = g_NetRxPackets[g_NetRxPoolHdr];
while (tmplen--)
*data++ = ETH_reg_read( RX_DATA_FIFO);
if (status & RX_STS_ES)
{
APP_TRACE_ERR("error, drop packet);
ret = ERROR;
}
else
{
g_NetRxPacketsLength[g_NetRxPoolHdr] = pktlen;
ret =(int)g_NetRxPacketsLength[g_NetRxPoolHdr];
}
g_NetRxPoolHdr++;
if (g_NetRxPoolHdr >= MAX_PACKETS) {g_NetRxPoolHdr = 0;}
}
}
return ret;
}
It seems that if a message from PC is send just before then next UDP message from PC, then it makes the target this kind of confusion as been described here,
i.e. if there is sending from PC of another packets (which is not part of this udp ping-pong test), then it results in this bad packets reception.
I have tried to think why this scenario can cause such behavior (loss of 4 bytes in packet), but don't have any clue yet.
Is this issue related to GPMC configuration ?
Best Regards,
Ran
