MPC5748G ENET Tx messages lost

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

MPC5748G ENET Tx messages lost

1,858 Views
cst
Contributor II

Hello,

we use the NXP DEVKIT-MPC5748G for evaluation/development.

At the moment we have a problem with the ENET interface.

 

On message transmission the ENET interface seemingly successfully transmits every frame, meaning all status registers and tx buffer descriptors look ok. But if we trace the network traffic, there are sometimes frames not transmitted/lost.

 

Has anybody the same issue? Is this maybe only DEVKIT related?

 

Appended is our testsetup for S32DS, using a DEVKIT-MPC5748G ENET code example.

Our simplified testsetup:

- Transmit UDP packet with a counter payload.

- Trace network packets with trace tool (Wireshark) for about 1min.

- Look for delta-time spikes. There is always a counter value gap of 1.

- Alternatively use a script on the test pc to check counter values (python).

 

Regards,

Christian Steur

Original Attachment has been moved to: mpc5748g_enet_rmii_udp.zip

0 Kudos
8 Replies

1,112 Views
Daniel_Wax
NXP Employee
NXP Employee

Please use the SDK UDP example.  The source code you posted uses some older bare metal examples that were written initially for an older version of the silicon as well as older eval boards.

Ive tried the latest SDK UDP example and with the latest eval board it works fine

0 Kudos

1,112 Views
jamesx
Contributor II

Hello Martin,

Do you have any findings on this problem?

we meet the same problem of not receiving all sent packets (about 5~6 out of 1000 packets are missed when send 1 UDP packet every 10ms, and the faster we send the more are missed), and it looks like it's an issue of packet corrupt which result wrong destination ip address/mac address in the ip/eth header, but we don't know why the packet data get modified after the call of 'ENET.TDAR.B.TDAR = 1;'

Any helps on this are appreciated!

0 Kudos

1,112 Views
martin_kovar
NXP Employee
NXP Employee

Hello James,

we have already faced this issue, but unfortunately, we have not identified the root cause yet. If I receive some new information, I will keep you inform. 

Regards,

Martin

0 Kudos

1,112 Views
kentsun
Contributor II

hi Martin,

   Do you have any update for this issue, Thanks!

0 Kudos

1,112 Views
cst
Contributor II

Hello Martin,

 

any news regarding this problem?

Can this be an error of the PHY on the DEVKIT-MPC5748G board?

 

Regards,

Christian

0 Kudos

1,112 Views
martin_kovar
NXP Employee
NXP Employee

Hello Christian,

sorry for long delay. I tested the board once again and there are some missing packet in every relation. It is not any systematic fault, because in every relation different packet misses.

I do not think it is error of the PHY, rather it looks like timing synchronization fault. I need more time to investigate, what is wrong, but if it is timing synchronization, it will be nearly impossible to repair it on DEVKIT board.

I have some tips for you which you can try right now:

1) Try to decrease speed to 10Mbit/s

2) I did not investigate your code deeply, just make sure you have always free buffer descriptor. Try to implement Transmit Frame Interrupt. This could help us to any software issue.

Regards,

Martin 

0 Kudos

1,112 Views
martin_kovar
NXP Employee
NXP Employee

Hello,

I tested your project and captured data using wireshark, but I am not able to find any gaps (it is nearly impossible to go through thousands of packets and check the value manually).

Could you please clarify me, what is delta-time spike?

Could you please send me log from wireshark and show me, where is counter gap?

Regards,

Martin

0 Kudos

1,112 Views
cst
Contributor II

Hello Martin,

thx for the reply.

I displayed a delta-time column in the trace to spot the errors.

Appended is a Wireshark trace of this test example with "missing"

counter payload (Message No. 10 and 95).

There the counter in the UDP payload jumps from 0x951->0x953 (No. 10)

and 0x9a7->0x9a9 (No. 95).

We think that the ENET is configured and used correctly for this simple

test.

But frames are lost somewhere without indications in status or error

registers.

Regards,

Christian

0 Kudos