AM4376: After Link-Up, first packet is not being transmitted

Stefan Pape

Part Number: AM4376

Hello experts,

we are using the EtherNet/IP adapter v1.0.3.4 on our hardware platform using a AM4376 CPU.

After initialization of the ICSS_EMAC and the PRU firmware a link is successfully detected on one external port and an interrupt is being issued. The ISR informs the ICSS_EmacLinkISR and the application about the changed link status.The application then sets-up a static IP address and then sends a broadcast ARP request to inform the network.

This first ARP request is not being transmitted on the Ethernet bus. On each following link loss and link up, always the first packet is being not transmitted.

At the point of time where ICSS_EmacTxPacket is issued, ICSS_EMacOsLinkTaskFnc has already updated the status of both PHYs (ICSS_EmacUpdatePhyStatus). Thus, the Ports should have been enabled and the packet should be transmitted.
When adding a breakpoint somewhere between the link interrupt (ISR) and ICSS_EmacTxPacket, the ARP is being sent, successfully.
Adding a delay of ~100 ms before calling ICSS_EmacTxPacket the first time, the ARP is being sent on the Ethernet bus.

So I assume, that the EMAC needs an amount of time after link-up before it is ready for transmission. Unfortunately, I could not find any hint in the documentation or in the example implementation (NIMU, NIMU_ICSS, etc.) concerning the need for a special delay.

How much time does the ICSS_EMAC need after link-up before it it ready for transmission on 100 MBit/s and 10 MBit/s?

If the delay is not constant, how can I poll the ready for transmission status?

Best regards

Stefan

over 4 years ago

0 Garrett Ding over 4 years ago

TI__Mastermind 43296 points

Stefan,

I don't think the delay is constant, will dig into the PHY status check function and get back to you next week.

Regards,
Garrett

0 Garrett Ding over 4 years ago in reply to Garrett Ding

TI__Mastermind 43296 points

Stefan,

I was hoping to get the timing measurement internally but we don't really have benchmark on the packet transmit latency. As the link is already up, i.e. link negotiation has completed, the packet should be able to transmit without such large latency of level 100ms. Which PHY are you using?

Regards,
Garrett

0 Stefan Pape over 4 years ago in reply to Garrett Ding

Intellectual 820 points

Hello Garrett,

we are using the TI-PHY DP83822.

Best regards

Stefan

0 Garrett Ding over 4 years ago in reply to Stefan Pape

TI__Mastermind 43296 points

Stefan,

Thanks. Let me consulting our PHY expert to see if they have any comments.

Regards,

Garrett

0 Garrett Ding over 4 years ago in reply to Garrett Ding

TI__Mastermind 43296 points

Stefan,

The issue is now tracked in our internal system. We will prioritize the issues you reported so far and try to address those ASAP.

Regards,

Garrett

0 Dhaval Khandla over 4 years ago in reply to Garrett Ding

TI__Mastermind 27764 points

Stefan
We tried to reproduce this issue. We are not seeing any packet loss after the link is going up. We see every packet being received on the host side, which DUT is sending.

I have few questions for you:

Can you try with link speed being forced(example, 100M full duplex)?
There might be some issue with the partner NIC. Can you try with a different NIC on host side?

Regards
Dhaval Khandla

0 Stefan Pape over 4 years ago in reply to Dhaval Khandla

Intellectual 820 points

Hello Dhaval,

the initialization of the ICSS_EMAC is triggered by our network initialization. An upcoming link directly notifies the application which then initializes the IP configuration and tries to send initial ARP packets.

I did some testing with two different NICs with automatic and fixed speed settings:

NIC: Intel(R) Ethernet I210-T1 GbE

Autonegotiation: Initial packets are lost on link up.

100M/HD/FD: Initial packets are lost on link up.

NIC: Intel(R) PRO/1000 PT

No packet loss detected.

Switch: D-LINK DGS-1210-10P

Autonegotiation: Initial packets are lost on link up.

100M/HD/FD: Initial packets are lost on link up.

It seems that the issue does not occur when using my "Intel(R) PRO/1000 PT" NIC which is quite an old hardware. Using a newer NIC or a managed switch, the issue can be observed.

Best regards

Stefan

0 Dhaval Khandla over 4 years ago in reply to Stefan Pape

TI__Mastermind 27764 points

Stefan

This looks like an issue regarding PHY startup time. Can you create a new thread regarding startup time optimization for DP83822 PHY, so that PHY team can help you with this?

Regards
Dhaval Khandla

0 Stefan Pape over 4 years ago in reply to Dhaval Khandla

Intellectual 820 points

Hello Dhaval,

thank you for your message. I created the a new thread to the interface forum:

https://e2e.ti.com/support/interface/f/138/t/956808

Best regards

Stefan

0 Stefan Pape over 4 years ago in reply to Stefan Pape

Intellectual 820 points

Hello Dhaval,

Adrian Kam has replied to the thread in the interface forum.

He asked me to switch the PHY into analog loopback mode to see, if the first packet reaches the PHY. I tried to do this and made the correspondung register changes. Additionally, I logged the receive packets to see what is looped back by the PHY.

Unfortunately, link interrupt event is missing in loopback mode, so that the ICSS_EMAC does not get into the state for transmitting packets.

Do you have any idea how to establish such a loopback test unsing the ICSS_EMAC?

Best regards

Stefan

0 Dhaval Khandla over 4 years ago in reply to Stefan Pape

TI__Mastermind 27764 points

Stefan

You can have a look at icss_emac test example in PDK, and see if it helps. You can find it in "pdk_am437x_*\packages\ti\drv\icss_emac\test\am437x" directory.

Regards
Dhaval Khandla

0 Stefan Pape over 4 years ago in reply to Dhaval Khandla

Intellectual 820 points

Hello Dhaval,

unfortunately, I could not find any example that switches the PHY into loopback and then unses the ICSS_EMAC driver to send and receive packets.

Regards

Stefan

0 Stefan Pape over 4 years ago in reply to Stefan Pape

Intellectual 820 points

Hello Dhaval,

with the support from the interface forum we could eliminate a problem on the PHY side.

So this thread can be closed. Thank you for your support.

Best regards

Stefan

Processors

Processors forum

AM4376: After Link-Up, first packet is not being transmitted