Ethernet Reception Issue

Hi,

I am still working on the Ethernet reception issue. I thought better to start a new thread as I was posting in someone else's thread.

While digging in to the Ethernet driver, I noticed that the variable "bds_in_chain" is not re-initialised to 1 in the "do.....while" loop in nx_rx_interrupt() function. This may cause issues with data reception if a new frame received while processing previous received frame in this function. For the new frame the variable will start from the value where it left for the previous frame and result in to pointing to invalid buffer descriptor for the new frame. 

Is this a problem and has anyone noticed that before? 

Thanks,

Meenanath

  • Good day, Meenanath!

    How are things going so far? Have you figured this one already? It seems that none has yet noticed your inquiry. I hope you could wait a while for the experts to comment on this. Thank you.

    Best regards,

    Sai
    RenesasRulz Forum Moderator
    https://renesasrulz.com/
    https://academy.renesas.com/
    en-us.knowledgebase.renesas.com/
  • In reply to Sai:

    Hi Sai,

    Thanks for your reply.

    This problem is time critical and you need to have Rx frames bigger than the buffer descriptor size. The variable "bds_in_chain" increases when frame occupies more than 1 buffer descriptor and while processing that frame in "do...while" loop the driver receives another frame with any descriptor size.

    After fixing this issue, I have started the test which is running for last 2 days and there is no problem so far. I will keep it running till Monday to confirm if our problem is fixed or not.

    Thanks,
    Meenanath

    I am copying the contents from another thread to bring our observation in this single thread.
    ----------------------------------------------------------------------------------------------------------------------------------------------------------------
    Hi Warren, Janet,

    There were couple of hardware issues in our design.
    1. There was voltage drop at KSZ8081RNA power supply due to a current limiting fuse. We observed the voltage to the IC was 2.8 volts which is not in the recommended list. We fixed this by removing the fuse.
    2. We had few resistors in the path between KSZ8081RNA and S7G2 because of IS reasons. The waveform was not looking good, so we removed the resistors and now the waveform is looking good.

    After fixing above hardware issues, we have not seen the eight leading zeros issue so far.

    Though we are facing another issue with the Ethernet reception. When we keep the system running for 2 to 3 days connected to the company network, the Ethernet reception stops working and when debugged we saw that the EDRRR.RR bit is cleared and does not set again. Usually we run the test on the weekend without any communication with the system over Ethernet. As the system is connected to the company network, it keeps receiving company network traffic, none of that goes to our application, so gets ignored or replied by the NetX stack. Monday morning most of the time the system does not respond to any messages and debugging shows that RR bit is 0.

    We saw that in nx_rx_interrupt() function there is code to set the RR bit to 1 if cleared, but it only happens when interrupt occurs. Our application does not transmit anything by itself and replies to the received queries only, so the interrupt does not occur.

    /** If reception is in suspended state, resume it. */
    if (nx_rec_ptr->edmac_ptr->EDRRR_b.RR == 0U)
    {
    /** Resume reception. */
    nx_rec_ptr->edmac_ptr->EDRRR_b.RR = 1U;
    }

    Can you please tell me what could be the reasons for EDRRR.RR bit to be cleared run time.

    Thanks,
    Meenanath

    ------------------------------------------------------------------------------------------------------------------------------------------------------------
    Hi Warren, Janet,

    Few more things that I observed while debugging this issue -
    1. RMFCR register value was 0x0000FFFF.
    2. EESR.RFCOF flag was set.

    The datasheet says when RFCOF flag is set, the reception stops. From the above register values looks like we are losing frames. Also the nx_renesas_synergy.c file does not handle RMFCR overflow and RFCOF flag.

    Not sure why we are losing the frames though.

    When we manually cleared the RMFCR register, cleared the RFCOF flag and set the EDRRR.RR flag the Ethernet started working with Rx buffer descriptors out of sync though.

    Thanks,
    Meenanath
  • In reply to Meenanath:

    The weekend test went well and Ethernet is running for more than 1 week without any problem.
  • In reply to Meenanath:

    Hi Meenanath,

    That's great! I hope you won't have any problem anymore with the Ethernet. Thanks also for sharing how you fixed the issue.

    JB
    RenesasRulz Forum Moderator

    https://renesasrulz.com/
    https://academy.renesas.com/
    https://en-us.knowledgebase.renesas.com/