Incorrect behavior when send/received small Ethernet frame

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Incorrect behavior when send/received small Ethernet frame

1,253 Views
alex_froissard
Contributor I

Hello,

I have a behavior than I don't understand, I send a Ethernet frame for ENET0 to ENET1 (they are connected together by a wire). When I send a frame bigger or equal to 88 Bytes everything work correctly, but if I try to send a frame smaller, at the reception the RxBD data length field is equal to 1520 bytes (value of the MRBR register).

The ENETs are in store and forward mode, the FIFO threshold are the default value.

The Ethernet configuration is RGMII 100Mbits/s.

I use the legacy buffer descriptor and the option to compute the CRC and send it by the MAC is activated.

Is someone has an idea about why I have this behavior?

Best regards

Tags (1)
0 Kudos
5 Replies

1,148 Views
EAlepins
Contributor V

This behavior is really similar to errata ERR050395 "ENET: Ethernet RX hang when receiving traffic through multiple queues" except that Alexandre is using a single ring... So we do not understand how we could fall into this errata...

Any idea?

Étienne

0 Kudos

1,148 Views
alex_froissard
Contributor I

Hello,

The problem is still persistent, I will describe what I did, and the result I get. On the image below you can see the configuration of both ENET and buffer descriptor for Tx and Rx.

The ENET0 is loop to the ENET1 with a cable. (Problem is present also in internal loopback)

The buffer descriptor are in enhanced 

- Tx BD (AS_ENET0_TXBD) : Length is set to 60 (0x3C) and option L (Last in frame), TC (Transmit CRC) and R (ready) are set

- Rx BD (AS_ENET1_RXBD) : Only the option E (empty) is set

- The transmission and reception are configured in store and forward

- Then the register ENET_TDAR is set to 0x01000000 to inform the MAC to start the transmission

   -> The field R of the TX BD is clear and the BDU (Last buffer descriptor update done.) is set by the MAC

   -> No error flag are raised in the Tx BD

   -> No interrupt flag are raised

   -> ENET_RMON_T_PACKETS is equal to 1 (one packet has been send)

   -> ENET_RMON_T_P64 is equal to 1 (one packet of 64 bytes has been send)

   -> ENET_RMON_T_OCTETS is equal to 0x40 (64 bytes has been send)

   -> ENET_IEEE_T_FRAME_OK is equal to 1 (one packet transmitted OK)

   -> ENET_IEEE_T_OCTETS_OK is equal to 0x40 (64 bytes transmitted without error)

- Then the register ENET_RDAR is set to 0x01000000 to received the data

   -> The field E of the Rx BD is clear, the field L set no set

   -> The data length of the Rx BD is set to 0x05F0 (Value of MRBR register)

   -> No error flag are raised in the Rx BD

   -> No interrupt flag are raised

   -> ENET_RMON_R_PACKETS is equal to 1 (one packet received)

   -> ENET_RMON_R_P64 is equal to 1 (one packet of 64 Bytes received)

   -> ENET_RMON_R_OCTETS is equal to 0x40 (64 Bytes received)

   -> ENET_IEEE_R_FRAME_OK is equal to 1 (one frames received OK)

   -> ENET_IEEE_R_OCTETS_OK is equal to 0x40 (64 Bytes received without error)

pb_small_msg.JPG

After that If a second message is send, the transmission will work but not the reception, it's like it's stuck.

I don't understand why the value write in the field Data length in the Rx BD is the value of the MRBR register whereas the counter show the reception of 1 frame of 64 bytes and no error are detected.

Best regards

Alexandre

0 Kudos

893 Views
AFR89
Contributor III

Hello,

We have found the origin of the problem, the value that was in the register MRBR was not divisibly by 64 like asking by the reference manual.

After we respect this constraint the problem disappear.

Best regards

Alexandre

1,148 Views
jimmychan
NXP TechSupport
NXP TechSupport

which product/chip are you using?

which bsp (and version) are you using?

0 Kudos

1,148 Views
alex_froissard
Contributor I

Hello,

I use the i.MX 8QuadXPlus.

We don't use bsp, we use it bare metal

best regard

Alexandre

Le lun. 22 juin 2020 à 15:51, jimmychan <admin@community.nxp.com> a écrit :

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: Incorrect behavior when send/received small Ethernet frame

reply from jimmychan

<https://community.nxp.com/people/jimmychan?et=watches.email.thread> in *i.MX

Processors* - View the full discussion

<https://community.nxp.com/message/1330247?commentID=1330247&et=watches.email.thread#comment-1330247>

0 Kudos