Ethernet: STM32 EMAC driver may return wrong frame length under heavy load

[artokin]

Description of defect

STM32 EMAC driver may return wrong frame length under heavy load

Target(s) affected by this defect ?

Detected only in DISCO_F769N

Toolchain(s) (name and version) displaying this defect ?

GCC_ARM

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.15.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

How is this defect reproduced ?

• Use DISCO_F769N as a Wi-SUN border router connected to the Internet via Ethernet connection.
• Have multiple Wi-SUN routers attached to the same Wi-SUN network and download a lot of content in each node.
• Downloading continues until the Border router gets jammed because of error detection code in Nanostack. In the logs there is a trace "Buffer length overflow".
• When "Buffer length overflow" happens, we see in our tests that Nanostack receives a 65518 bytes long Ethernet frame from the STM EMAC driver.

Please note! At the moment Nanostack is not able to recover from such a long frame but it will be fixed in a separate ticket.

cc: @mikaleppanen , @teetak01 , @mikter

[0xc0170]

cc @ARMmbed/team-st-mcd

[jeromecoutant]

ST_INTERNAL_REF 81312

[jeromecoutant]

Hi @artokin

Question from ST driver team:

The packet length is calculated based on the status fields (RDES0) of the descriptors:

/* Get the Frame Length of the received packet: substruct 4 bytes of the CRC */
heth->RxFrameInfos.length = (((heth->RxDesc)->Status & ETH_DMARXDESC_FL) >> ETH_DMARXDESC_FRAMELENGTHSHIFT) - 4;

Can you please share the value of receive frame status ((heth->RxDesc)->Status) when issue reproduced to verify if there is no error and the last descriptor is set when getting the data length:

These bits indicate the byte length of the received frame that was transferred to host memory
(including CRC). This field is valid only when last descriptor (RDES0[8]) is set and descriptor error
(RDES0[14]) is reset.

[jeromecoutant]

@artokin
Did you have time to check ST driver team question from my previous comment ?
Thx

[artokin]

@jeromecoutant , we have tried three times but unfortunately we are not able to reproduce the original error.

[jeromecoutant]

@jeromecoutant , we have tried three times but unfortunately we are not able to reproduce the original error.

So maybe we should revert #12457.....

[artokin]

Or would it be better to have #12457 there in case we see the problem again in the future?

[0xc0170]

@jeromecoutant @artokin What shall we do here? After 12776 merged, this can be closed?