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.

AM2434: TX CRC32 is sometimes not output

Part Number: AM2434

Tool/software:

Hi,

We are using custom PRU firmware.
Sometimes the CRC32 is not added to the transmitted packets from the PRU.
It seems that it is not in the TX L1 FIFO because the TX FIFO level does not change when TX_CRC_HIGH is set.
So we would like to know the following:
What is the condition to start the TX CRC computation?
Is there a way to reset the TX CRC calculation function?

Our flow is as follws:
1.Check that the RX_SOF bit is 0 in the INTC Raw Status Register 1
2.Change the data path (change MII_RXCFG, MII_TXCFG)
3.TX_RESET
4.Write data
5.Check the TX_FIFO_LEVEL that 8 nibbles or more are free in
6.cmdR31 [TX_CRC_HIGH + TX_CRC_LOW + TX_EOF]

The data path is "Auto-forward with PRU Snoop" to "32-byte Double Buffer or Ping-Pong Processing".
(TRM 6.4.11.2 MII_G_RT Functional Description)
Observing the operation, it seems that this can occur when the data path settings and the timing of packet reception match.
(After changing the data path, the RX_SOF bit is set in Raw Status Register 1.)


Regards,
Takashi

  • Hello Takashi,

    Please note that we can support questions about the PRU and basic PRU programming, but after a certain point we are limited in the support we can offer when you are programming something as complex as your own networking interfaces.

    I am reassigning your thread to another team member to comment, but they may be limited in the support they can offer.

    Regards,

    Nick

  • Hello Nick,

    Thank you for your comments and consideration.
    We hope this clarifies the behavior of the device.

    Please note that MII_G_RT is used with MII, 100Mbps, Full-Duplex.
    The evaluation board is TMDS234EVM.

    Regards,

    Takashi

  • Check the TX_FIFO_LEVEL that 8 nibbles or more are free in

    What's the size assumed for L1 TX_FIFO here? Note that it is reduced to 32B from AM3/AM4/AM5 which had 64/96/96 bytes. You can increase the effective size to 96 bytes using this together with TXL2 FIFO which is 64 bytes.

    Do you see any errors in INTC ICSS_INTC_RAW_STATUS_REG0 and ICSS_INTC_RAW_STATUS_REG1 when this issue occurs?

  • Hi Pratheesh,

    Yes.
    Our program controls the flow level to be 32 bytes or less.
    And no errors have occurred. TX_OVERFLOW, TX_UNDERFLOW are not set, too.

    TRM describes TX L1 FIFO has 40 or 96 bytes, but 32 bytes is correct, right ?

    Regards,

    Takashi

  • The data path is "Auto-forward with PRU Snoop" to "32-byte Double Buffer or Ping-Pong Processing".
    (TRM 6.4.11.2 MII_G_RT Functional Description)

    Confused about this one, Auto Forward also implies MII RT HW will forward from RX L1 to TX L1 directly without firmware intervention. 

    Our flow is as follws:
    1.Check that the RX_SOF bit is 0 in the INTC Raw Status Register 1
    2.Change the data path (change MII_RXCFG, MII_TXCFG)
    3.TX_RESET
    4.Write data
    5.Check the TX_FIFO_LEVEL that 8 nibbles or more are free in
    6.cmdR31 [TX_CRC_HIGH + TX_CRC_LOW + TX_EOF]

    Not clear how and when above sequence is followed in the context of Auto Forward with snoop.

    TRM describes TX L1 FIFO has 40 or 96 bytes, but 32 bytes is correct, right ?

    TXL1 FIFO is 40 bytes including 8B preamble (which can be automatically depending on configuration and in most cases transparent for firmware).

    Can you share detailed ICSS MII RT settings and any wireshark logs if possible

  • Hi Pratheesh,

    Under normal circumstances, the configration is set to the auto forwarding. The setting is changed when the FW wants to send its own packets. To switch when there is no packet in the transmission path, the FW refers to INTC to confirm that it has not been received before switching.
    I don't want to disclose the MAC address and frame type to the public on the forum, so it is difficult to present the log file, but the settings are as follows.

    A:
    MII_G_RT_RGMII_CFG : 0x00010101
    MII_RT_RXCFG0 : 0x00000055
    MII_RT_RXCFG1 : 0x0000005D
    MII_RT_TXCFG0 : 0x00400201
    MII_RT_TXCFG1 : 0x00400301

    B:
    MII_G_RT_RGMII_CFG : no change
    MII_RT_RXCFG0 : no change
    MII_RT_RXCFG1 : 0x0000001D
    MII_RT_TXCFG0 : no change
    MII_RT_TXCFG1 : 0x00400906

    Change from A to B.
    After setting to B, push the data and then set TX_ENABLE1=1.

    Regards,
    Takashi

  • The following is an excerpt of packets obtained with other capture tools. Cases that were as expected and those that were not are described. MAC addresses and other information in the packets have been replaced with XX.

    packet_log.xlsx

  • Under normal circumstances, the configration is set to the auto forwarding. The setting is changed when the FW wants to send its own packets. To switch when there is no packet in the transmission path,

    I suggest using R31 TX_EOF status to make sure that there is not packet in transmission path. Configure MII_RT_RXCFG. RX_DATA_RDY_MODE_DIS = 1 for this 

    1.Check that the RX_SOF bit is 0 in the INTC Raw Status Register 1
    2.Change the data path (change MII_RXCFG, MII_TXCFG)
    3.TX_RESET
    4.Write data
    5.Check the TX_FIFO_LEVEL that 8 nibbles or more are free in
    6.cmdR31 [TX_CRC_HIGH + TX_CRC_LOW + TX_EOF]

    Do not see a need to TX_RESET (unless you are running into an error condition), please check by removing TX_RESET from your flow.