Ethernet RX assertion

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

Ethernet RX assertion

Jump to solution
4,224 Views
pjanco
Contributor III

Hi,

I have own board design based on EVK-MIMXRT1060. When transferring large data over TCP/IP in direction from my PC to IMXRT board, it very often ends in this assertion and then restart on watchdog.

 

 

LWIP_ASSERT("Buffer returned by ENET_GetRxFrame() doesn't match any RX buffer descriptor",((idx >= 0) && (idx < ENET_RXBUFF_NUM)));

 

 

I am currently using SDK 2.11.0 but I noticed that in changelog for SDK 2.13.0 is this bugfix:

port: Fixed copying of pbuf contents. Previous code was using an incorrect end
condition and could result in the overrun of the destination buffer if more packets were
on the queue.

It is possible that this can fix mine bug. But migration between SDK versions is so hard with NXP.

I prefer to stay with old SDK and just fix this bug.

Can you provide short bugfix of this overrun for SDK 2.11.0 ?

 

Labels (1)
0 Kudos
1 Solution
3,399 Views
AbnerWang
NXP Employee
NXP Employee

Hi Peter,

Great! Although I still can't reproduce this issue on my local environment with your code, maybe result from laptop performance. But I think I can make an conclusion now.

Previously we have GetRxFrameSize before ReadFrame to check Rx frame status for non-zero-copy case. There's the code snippet in GetRxFrameSize:

/* Add check for abnormal case. */
if (curBuffDescrip->length == 0U)
{
isReturn = true;
result = kStatus_ENET_RxFrameError;
break;
}

When adding zero-copy function, I didn't use this logic because I never meet this corner case and consider it a redundant operation. And this IP is very old, I can't find software/IP designer to review the history. Now I will think this is an ENET IP issue, so also add this check for GetRxFrame. Meanwhile I improve the code logic to check all EMPTY flag valid in case other corner case occurs and driver returns success. Attachment is the function with fix. Can you try and tell me the result?

Best Regards.
Abner

View solution in original post

23 Replies
1,184 Views
pjanco
Contributor III

Hi,

thanks, great job!

I can confirm it solve the problem on my IMXRT1060-EVK board with my testing project "evkmimxrt1060_TEST_lwip_httpsrv_freertos".

With my testing project, I am able to trigger error behavior within few seconds. It is weird that on your side, you can not trigger the problem like me.

Also for unknown reason, today I am not able to trigger the error behavior with my real project during OTA upgrade to flash. But It was like this even before. Some days problem occurs very often and other days not.

I believe it is solved with your new ENET_GetRxFrame function.

 

Regards,

Peter

 

1,152 Views
AbnerWang
NXP Employee
NXP Employee

Hi Peter,

Previous code has certain reason to do this although I can't get any more info except that code and simple comment, I believe it should be helpful to fix this issue. This abnormal case looks very like an ENET IP issue, I need more time to dig the root case through software history log and design team's help.

This is my first time to do tech support in NXP Community. Wish you could give me Kudos to encourage me.

Best Regards.
Abner
895 Views
danielchen
NXP TechSupport
NXP TechSupport

Thanks, I will forward this to develop team.

Regards

Daniel

0 Kudos