RTOS/TLK110: system will hang-out with high-traffic

Hi Abby,

False Carrier Counter is incremented when the received signal's symbols cannot be decoded, or the PHY's internal CDR cannot lock onto the symbols to recover the clock properly.

Do you have the RMII enhanced mode enabled?

Best Regards,

Hi Rob,

Thanks for your reply.

We didn't enable RMII enhanced mode.

Should we enable it?

Abby

Hi Abby,

You can try enabling it. Also, are you providing the 50 MHz reference from the AM3359 or an external oscillator?

If you are using an external oscillator, can you share the datasheet? I want to see the jitter spec.

Best Regards,

Hi Rob,

We use an external oscillator as the below link: (3.3V, ±50ppm)
www.siward.com.tw/.../_P1-72_49.pdf

Except "False Carrier" issue, what may cause the TLK110 hang-out? Which registers can we check?
Because we found "False Carrier Counter" didn't increase but the system still hang-out sometimes.
Or do you have any suggestion for us to check AM3359?

Abby

Hi Abby,

It is unusual to have the TLK110 port hang up. In fact, slowing the interface I suspect is happening in the upper layers, and a reset of the TLK110 is causing the port to reset.

When running a lot of packets through a microcontroller, it is common to exceed the message handling capability of that subsystem, especially when the packets are relatively small and the IPG is short. This causes a very rapid string of interrupts in the controller, or it causes the MACs buffer to overflow before the microprocessor can handle it.

You can tell if the PHY is having a problem by looking at the RX_ER counter and the FCS counter. If those 2 counters are increasing during operation, then you likely have an issue with jitter on your reference clock.

The oscillator datasheet you provided does not specify jitter, so I am concerned it may be high.

The AM335x also requires a low jitter RMII reference clock to work with.

Can you provide your schematic of the TLK110 design? In that original thread you referenced before, there was an error in the schematic that was likely causing problems.

Best Regards,

Hi Rob,

We will try to get a low jitter OSC to test.

When we do the high-traffic test, the system did not hang immediately.

The time of hang-out is random.

Our schematic of TLK110 is as below:

Thank you.

Abby

Hi Abby,

The schematic looks OK.

What is the behavior of the PHY's registers when your communication hangs? What is the status of the LED_ACT? Does the PHY still show activity?

Can you provide a dump of register values from 0x0 to 0x1f during normal operation? Also provide a dump of register values 0x0 to 0x1f when the communication hangs.

Best Regards,

Hi Rob,

We use AM3359 to read PHY's registers, when the communication hangs, AM3359 can't read PHY's registers anymore.

Do you have other suggestion to read PHY's registers?

Thank you.

Abby

Hi Rob,

We got three OSC:
(1) DSC1001AIZ-050.0000
ww1.microchip.com/.../DSC1001 Datasheet MKQBPD05061001-8.pdf
(2) FN5000118
www.diodes.com/.../FN_3-3V.pdf
(3)X1G004481001200
www.texim-europe.com/getfile.ashx

Q1: Could you help to check which one is better for our application?
Q2: In our schematic, the OSCOUT connects to two PHYs (two ethernet ports). Do we need two OSC to connect to each PHY?

Thank you.

Abby