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.

C6678: Ethernet RX message truncated

Other Parts Discussed in Thread: SYSBIOS

Hi,

I'm in trouble receiving packets from the Ethernet: the received packet len always seem to be truncated. The len is variable but always truncated , normally range from 28 to 32 bytes when receiving and ARP request. The message data appears to be corrected up to the declared len, while the trailing bytes seems to be unchanged (not transferred by the DMA).

I use a custom board with a Marvel PHY 88E1512, and a custom driver (no NDK or SYSBIOS) that works on the EVM. The Marnell driver is imported from u-boot (errata work around already implemented), and the 1000 MHz half duplex mode should be disabled (if I have correctly patched the code)

The C6678 Ethernet STATB message count is correct while the RX message is always multiple of 64 bytes in accordance with the real messages size rounded up to a minimum of 64 bytes.

The packet size extracted from the queue descriptor is incorrect but in accordance with the bytes transferred to my host buffer. I look around in the Giga Ethernet module but there are no errors reported. Also the PHY seems Ok (but maybe I  don't look at the right registers).

When I enable the Marvell packet generator with a size of 64 bytes, I can receive all the message but with a variable size between 24 to 42 bytes, more or less).

I wonder if someone have a suggestion on where to look to investigate the problem, at least to understand if I have to look at the C6678 setup or at the Marvell PHY setup.

I apologize this is a partial report of my previous question Problems C6678 + PHY 88E1512 (https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/531640

  • Hi Alberto,

    I've notified the ethernet experts. Feedback will be posted here.

    Best Regards,
    Yordan
  • Hi,

    Any suggestion about this problem?

    I tried various configuration but without success. I also try to start from scratch from the EVM TI POST code. The received messages are always truncated to 28 bytes, apparently without any errors

    I really need some suggestion how to investigate the problem.

    The test project:

    1. Rebuild POST ethernet test on EVM: OK.

    2. Modfied for a custom board with 88E1111 (as EVM): OK  (little changes in the SERDES setup to meet my custom board clocks and configured as RX slave)

    3. Modified for custom board with 88E1512:

       a. Marverl 88E1512 initialization

    With this version, using only ARP messages:

    - the SGMII links are always  up, without errors on both C6678 SGMII side and PHY size

    - Th copper side is OK (I try with auto negotiation and also forcing 10/100/100, always full-duplex)

    - TX works without problems

    - MAC statistics never reports errors. The number of good frame are in accordance with the received messages, the number of bytes is always multiple of 64

    - RX message on the RX queue are always truncated to 28 bytes (The configured MTU is 2048 bytes, the buffers are allocated as per TI POST example)

    - The transferred bytes are always correct and correspond to the first 28 bytes of the ARP message.

    To exclude the copper side, I tried to use the Marvel Internal Packed generator of 64bytes len messages: the result is always the same, the message appears to be valid but truncated to 28 bytes

    Note that even if ARP message and marvel patter give me always 28 bytes, other message form my PC sometime give different len. For instance some messages of 82 bytes are truncated to 40 bytes.

    To try to isolate the problem, I tried also to bypass the PA PDSP0, but the results is the same.

  • Hi,

    Since, on the C6678 side:

    1. the SerDes he link is up andf locked, auto negotiation ok

    2. SGMII is OK

    3. TX messageas are correctly transmitted on the cable

    4. RX STAT are always good without CRC error

    Can I assume the PHY configuraiton and SGMII I/F are correctly configured and the HW connections are OK?

    How the MAC determine the message len?

    As far as I know the checksum is the last 4 bytes of the message, so if the MAC do not report CRC erroros, the message from teh PHY to the SGMII has been correctly received and has the right len.

  • Hi,

    I did a step further in my problem: Instead of using the TI POST code, I completely rewrite the Ethernet driver from scratch and now both RX and TX seem to work (even if I found a new strange problem but also a temporary fix, maybe I will open a new thread about this).

    Unfortunately so far I'm not able to identify the difference between the two versions (TI Sw and my SW). After the initialization, the ETH subsystem registers look more or less the same.