This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: Delay in Receiving the UPD Messages over the Ethernet

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hi Team,

We are using EMAC and MDIO drivers of TMS570LC4357 for Ethernet communication. So, as per our requirement on system boot-up, the UDP messages will get transmitted within 500 ms of time. But we see that after the ethernet's initialization, the UDP messages that we are sending are not getting transmitted at all and we are not getting any packet on the Wireshark. So, to do that we have to insert the delay of a minimum of 2.5 seconds after the system boot-up and before the transmission of UDP messages. We are using the DP83848 PHY chip for ethernet communication.

So, can you please provide any justification or resolution like why we have to give the delay of a minimum of 2.5 seconds before transmitting the UDP messages.

Thanks & Regards,

Parth

  • Hi Parth,

    I am sorry I don't a working UDP example. The device boot-up doesn't take more than 100ms. Is the delay inserted inside the emac driver?

  • We are using the DP83848 PHY chip for ethernet communication.

    Is the DP83848 set to auto-negotiate link speed and duplex with the remote link partner?

    While for a DP83849 which is a different 10/100 Mb/s PHY, Auto-Negociation Time says the auto-negotiation will only start 1500 milliseconds after power-on reset completes and the basic auto-negotiation can take roughly 300 - 500ms. I.e. the auto-negotiation could be taking 2 seconds from power-on reset to complete meaning the TMS570LC4357 wouldn't be able to transmit any packets in that time.

    Not sure if disabling auto-negotiation at both ends of the link would decrease the time for the link to come up. 

  • Hii and @Chester Gillon,

    Thanks for the reply.

    I.e. the auto-negotiation could be taking 2 seconds from power-on reset to complete

    One thing I need to correct is that we are using a DP83822 PHY chip instead of a DP83848 PHY. 

    So, for the DP83822 PHY chip also the observations are the same only as you mentioned for DP83849..?

    Thanks & Regards,

    Parth

  • So, for the DP83822 PHY chip also the observations are the same only as you mentioned for DP83849..?

    From just looking at the DP83822 datasheet I'm not sure. Suggest you ask that a question about the DP83822 link-up time on the Interface forum.

    However, before you do that can you put some diagnostics in the software to check if the link-up time is the cause of the problem or not?

    E.g. use the HALCoGen MDIOPhyRegRead() function to read from the DP83822 Basic Mode Status Register (BMSR) and check for how long after reset before the Link Status bit is set meaning a Valid link established.