• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 149 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

PRU-ICSS-INDUSTRIAL-SW: Support required for accessing PRU-ICSS EMAC firmware

PRU-ICSS-INDUSTRIAL-SW: Delay in transmitting last bytes of the packet in PRU core

Jayakumar N
Prodigy 20 points
Part Number: PRU-ICSS-INDUSTRIAL-SW

Tool/software:

Hi All,

We are working on the PRU core on AM437x IDK, and we came across a specific function call (M_XMT_FILL_LEVEL_CALC_ICSS_REV1) which is invoked during the last byte transmit of every packet from the PRU firmware. The comment in the file (emac_MII_Xmt.asm) states that the function is called to fix an issue if there is an underflow or overflow in the TX FIFO when cable is removed during the high traffic scenario.  But invoking this function causes a delay in transmitting the last bytes of the packet. This causes to capture malfomed packets in the wireshark. This is observed only in the Windows system. Could somone explain what does this function (M_XMT_FILL_LEVEL_CALC_ICSS_REV1) exactly does while transmitting the last chunk of the packet which is causing the delay.

File name: git.ti.com/.../emac_MII_Xmt.asm

  • 0
    TI__Expert 7325 points

    Jayakumar,

    I am  assuming you are using the EMAC example here. There is a bug which we identified recently in the code that might cause the issue you are observing.

    You need to make sure the TX SOF value is read before you call the function M_XMT_FILL_LEVEL_CALC_ICSS_REV1 (used to calculate the TX FIFO fill level). Can you add the below code before calling the function and try

       .if $defined("ICSS_DUAL_EMAC_BUILD")
    .if !$defined("TTS")	
;Only need to read in non-TTS EMAC.
;For TTS EMAC, it is read in M_TTS_FIFO_FILL_MOD-->M_TTS_TX_SOF_COMPARE_ICSS_REV1.
    .if $defined("ICSS_REV1")	
    M_XMT_GET_TXSOF_ICSS_REV1
    .endif	;ICSS_REV1
    .endif	;TTS
    .endif  ;ICSS_DUAL_EMAC_BUILD

    ; port tx sof capture for port 1 (PRU1) and port 2 (PRU0) - 2 port config.
    .if $defined("TWO_PORT_CFG")	
    .if $defined("PRU0")	
    LBCO	&TEMP_REG_3, IEP_CONST, CAP_RISE_TX_SOF_PORT2_OFFSET, 4	
    .else
    LBCO	&TEMP_REG_3, IEP_CONST, CAP_RISE_TX_SOF_PORT1_OFFSET, 4	
    .endif
    .endif ;TWO_PORT_CFG

    Regards,
    Prajith

  • 0 in reply to Prajith Jayarajan
    Prodigy 20 points

    Hi Prajith,

    I have tested the firmware by including the above code inside XMT_LB function call as you have mentioned, but still I observed the malformed packets being captured in the wireshark. For testing purpose, I have removed the M_XMT_FILL_LEVEL_CALC_ICSS_REV1 function call inside the XMT_LB function, to the surprise I did not observe any malformed packets getting captured in the wireshark. Is removing this function the right approach or please suggest any alternative?

    Regards,
    Jayakumar N

  • 0 in reply to Jayakumar N
    TI__Expert 7325 points

    Hi Jayakumar,

    Could you share the updated code here?

    The code in LB is meant to detect error condition and reset the FIFO. If you comment the code this part does not execute and the communication works correctly. But you are missing the error handling in this case which wont be coming up in basic testing. I would recommend to fix the error handling. Please share the updated code, i will confirm and let you know

    Regards,
    Prajith