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.

C6672 - PA_simpleExample Ethernet internal/external loopback RX fails after 52 bytes

Hello,

we have developed a custom PCB based on the C6672 DSP. Both Ethernet channels are connected to an FPGA through SGMII. The SGMII signals are converted in the FPGA into GMII.

To validate the SGMII link between the DSP and the FPGA, we have modified the PA_simpleExample example code for our hardware. The test consists of using the LOOPBACK_EXTERNAL setting in the simpleExample code. The 'pktMatch' packet is then sent from the DSP over the SGMII link to the FPGA, where the data is looped back at the GMII side so the packet is sent back from the FPGA to the DSP over the SGMII link.

This seems to work, mostly. In the FPGA we can verify that the pktMatch packet is correctly received and sent back into the transceiver. However, on the DSP side bytes are missing when the packet is received again. The findPacket() function is returning the error '[C66xx_0] function findPacket: Byte 52 expected 0x3c, found 0x3f' or something similar, but always starting at byte 52. The received packet is generally 30 bytes shorter than the size of pktMatch. There's not a fixed pattern of which bytes are corrupted after offset 52, but the corruption always occurs after the 52nd byte.

The weird thing is that the same issue occurs when using LOOPBACK_INTERNAL, which should loop back the data before leaving the DSP on the SGMII. Using LOOPBACK_PA works correctly.

Any idea what could be causing the problem? Any help is greatly appreciated!

Best regards,
Oane

  • How many packets are you sending ?
    Have you modified the PA example code ?
    Could you tell us what is PDK version using ?
  • 1) We're sending just one packet through sendPacket() and then hoping to receive it intacly through findPacket() at this point in time.

    2) The only modifications we made to the source code of the example are pretty much only in the 'cpsw_mgmt.c' source file, since our input clock rate is different for SGMII (250 instead of 325) and some additional changes concerning PHY management which weren't present in the example.

    3) We are using PDK 1.1.2.5 for this example currently.

  • Luckily it turned out to be as trivial as I hoped it would be: the PLL of PASS was not properly initialised by the GEL file. Similar issue as was described here: e2e.ti.com/.../1360375

    Everything is in working order now, looping back packets in the FPGA that are verified by the DSP. A good low level test to verify the SGMII link between the DSP and the FPGA since it's very hard to actually measure those signals.