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.

SGMII link fails

Other Parts Discussed in Thread: CDCE62005

I've seen a few posts on this topic but the poster always seems to vanish before a resolution is posted.  I have a custom c6678 board and can't seem to get an SGMII link.  We are using SGMII'0' rather than SGMII'1' and our clock is 250MHz but the phy is the same as the EVM board.  I'm trying to integrate the c6678 client example project into mine.  The failure happens in Init_SGMII(0);      

at

do
{
       CSL_SGMII_getStatus(macPortNum, &sgmiiStatus);
 } while (sgmiiStatus.bIsLinkUp != 1);

I've modified the platform library to use CSL_BootCfgSetSGMIIConfigPLL (0x00000051); in configSerdes(); to reflect our clock speed of 250 MHz instead of the 312.5MHz on C6678 demo board(and I do not have a demo board to test against mine);

and use Init_SGMII(0); rather than '(1)'.

Is there another modification I have to make based on the clock difference?  Is the code I'm using appropriate(platform lib for c6678 and EVM_init()  ->platform_init() as seen in the c6678 client example? The platform_init() call uses only the phy and time stamp clocks as used in the example.  Time stamp clock seems to run fine and configSerdes() seems to work after my change to the PLL config value.  What might be useful to focus on?  Status bits?  Verify some parameters?  Any ideas?

  • Wanted to add that I'm making this as simple as possible.  I've added only Global Network Settings to my project from SYS/BIOS.  Not sure if any additional modules need to added to get the SGMII link up.

  • I added : CSL_SGMII_disableAutoNegotiation (macPortNum); and the link worked but this seems to have been a coincidence.  I have not been able to get a link again.

  • Hi,

    we have the same problem (see http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/215224.aspx) and it is still unsolved.

    Some Questions:

    - Have you tried the loopback tests?

    - Can you access the PHY's MDIO registers?

    - Can you see data traffic on the Rx/Tx lines using an oscilloscope ?

    - In the case when the link came up, was just the SGMII  link bit set or was the link completely operational, i.e. could you transfer data (even without autonegotiation)?

    Regards, Marcus

  • We also seem to have a similar issue on a new board which is a copy of the Advantech EVM schematic with the Marvell PHY, but using a 250 MHz SGMII clock input.  I haven't had time to probe it further as there is other board commissioning work to do.  I suspect we have some issues with our CDCE62005 clock generation and will investigate that first.

    Would be very interested to hear if/how you resolve this.  Thanks!

  • Haven't tried a loopback test.  Did try some mdio_init code found here: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/196299.aspx which worked.  Initially the phy was dead anfd we discovered the company we sent out boards to was frying the phy,\.  Not we have it mounted correctly we see the phy alive and mdio access works.  Not seeing data traffic and unable to get a link up on the SGMII still.  The one time was a random fluke when our phy was fried so we couldn't see any data transfer.

  • Our problem turned out to be to do with the SGMII clock input, once that was fixed the link just started working.  Surprisingly easy!

  • Gordon,

    that sounds promising. Can you give some more details about the clock problem? Was the frequency wrong or a jitter problem? And did you change the register settings of the BCM phy via MDIO or is the phy operational with the default settings after power up? These information would be very helpful, since we could not fix the problem so far.

    Thank you very much

    Marcus

  • All the clocks are coming from a single CDCE62005 (ie. the same chip as the EVM, but a slightly different configuration) with a 25 MHz crystal oscillator on the AUX input.  We found our clocks were 8% too slow.  We eventually measured the frequency across the crystal with an appropriately high-impedance probe and found it was also 8% down.  This chip turns out to be very sensitive to the capacitance across the crystal, and due to a part that was mis-described on the supplier's website we had the wrong capacitance.  (This is clearly explained in the clock chip datasheet, once you think to look for it). Fortunately this was easy to fix by changing the capacitor.

    The DSP didn't like this whole state of affairs much and had been generally flaky, but is much better now.  Also the SGMII exhibited the symptom described above, that the link just didn't come up, presumably because the PHY has its own idea of correct clock rates.

  • Did you check the lock bit of the SGMII PLL when using the old capacitor? Has the PLL locked even if the frequency was too low?

    We use a two-stage CDCE design similar to the EVM. The SGMII clock is generated by the second CDCE which gets its reference clock from the first one. However, we drive also PCIe from the second CDCE and PCIe is pretty stable in our system.

  • Yes, the lock bit was 0 with the old capacitor and is now 1 after configuring SGMII. 

  • Hello, how did you fix this problem, I am also troubled with problem. Could you give me some advice? Looking forward for you reply anxiously! Thank you very much!!!

  • This is an old post. You might get quicker answers if you create a new post with a clear description of your problem.

    I had some problems with SGMII on our first C6678 board because the oscillator on the clock chip was not exactly the right frequency but was 8% low. (The Colpits' oscillator was very sensitive to PCB capacitance) The C6678 can lock PLLs in this case but the PHY will not accept a clock that is so much out of specification. There are various ways to check the clock, the simplest might to measure the UART or other peripherals that use a clock divider.

    I am sure there are other ways SGMII can fail. Try to write a full explanation in a new post.

    Best of luck,

    Gordon
  • No, we could not fix this problem. We spent a lot of time analyzing the signal integrity on the SGMII lines but without finding any issues there. At least, we can exclude a problem with clock stability since we use PCIe on the same board without any problems. We assume that there may be a problem with the voltage regulators for the phy that prevents the phy from transferring data to the C6. Also the register configuration of C6 and phy are correct.

  • Hi, Gordon, thank for your reply!

    My board's clock is generated by two CDCE62005. One generates two 100M and one 66.67M, and one 100M for CORECLK, another one for REFCLK used by the second CDCE62005, and 66.67M is for the DDRCLK.

    On my board, DSP CORECLK makes DSP work well, and DDR3 can run at 1000MHZ. The second clock chip generates 312.5MHZ for SGMIICLK, when I config the SGMIIPLLREG, the pll can not be locked. The problem on my board is the SGMIICLK's instability? But I test the EVM with  oscilloscope, it is also not very stable.

  • This is not really my area of expertise. It seems you are now able to split your problem:
    - are the CDCE62005 chips producing a good clock?
    - if so, is the DSP SGMII PLL configured correctly?

    You need a good scope and differential probe to measure the clocks well. The CDCE62005 has a software package that can be used to configure them and try different settings. Our TI rep was able to get advice on the use of this part as well. You might try other forums to ask about the clock chip.

    One thing we did find was that when the CDCE was struggling, it got very hot, but when we fixed the oscillator it did not run hot. That may depend on the current pump settings though.

    Best of luck,

    Gordon