Post Go back to editing

BF607 EMAC DMA Rx into RU status

Hello

I met an issue when use BF607, when there is a network storm, the EMAC DMA Rx direction will into RU status (EMAC_DMA_STAT.RU = 1), and the DMA will be suspended. Following the manual of the BF607, the description about RU is as follow:

The EMAC_DMA_STAT.RU bit indicates that the Next Descriptor in the Receive List is owned by the application and cannot be acquired by the DMA. Receive Process is suspended. To resume processing Receive descriptors, the application should change the ownership of the descriptor and issue a Receive Poll Demand command. If no Receive Poll Demand is issued, Receive Process resumes when the next recognized incoming frame is received.

According to the description about RU, when DMA go into suspend status, I clear all the descriptors list and change the status of descriptor as DMAOWN:

for ( i = 0; i < RX_BUF_NUM; i++ )

{

    uint8 *p = (uint8 *)(pDmaDesc->StartAddr);
    flush_data_buffer(p, p + ETH_FRAME_BUF_LEN - 1, 1);
    pDmaDesc->ControlDesc = ETH_FRAME_BUF_LEN | (1UL << 14); // use next descriptor
    pDmaDesc->Status |= ADI_EMAC_DMAOWN; // OWN is DMA

    pDmaDesc = pDmaDesc->pNextDesc;

}

And then write rx poll register as 0 to issue a receive poll demand:

*pREG_EMAC0_DMA_RXPOLL = 0;

However, it does not work anymore, the DMA is still in suspend status, and I check the EMAC_DBG.RXFIFOST, it is in Rx FIFO Full status all the time.

How can I deal this issue when DMA go into suspend status?

Thread Notes

Moved from ADSP-BF60x to CrossCore Embedded Studio and Add-ins on Wednesday, November 8, 2023 5:07:25 AM by Divya.P

  • Hi LiLongFei,


    We are looking into this issue, will get back to you soon.


    Regards,
    Divya.P

  • Update some information:

    I do another test:

    Ping the device by PC continuously, then stopping application receive process, and there will be a RU interruption triggered, we do resume receive process just like above in interruption handle function and resume application receive process, the receive process can  resume.

    Same operation just like above, but we do not do resume receive process operation in interrupt handle function, only set a flag to indicate that there is a RU in DMA, in the receive package task we check the EMAC_DBG reg if the RX FIFO of the DMA is full (RXFIFOST = 3), if it is full we do the resume operation, the communication can not resume, the DMA status reg is  0x660000, EMAC_DBG is 0x140, according to these two regs, the receive process looks like has been resumed.

    Why can this situation exist?

    Hope for your reply.

    thanks a lot.

  • Hi LiLongFei,


    It looks like the application is not fast enough to change the OWN bit in descriptors when there’s a sudden burst of traffic.

    If EMAC address filtering is programmed, the EMAC wont waste time on unwanted traffic on the network. That could be one suggestion to try.


    Regards,
    Divya.P

  • Hello Divya

    Yes, when the issue happened, there was a net storm (the background system ask so many data from device in a short time). And EMAC address filtering has been used, this filter mechanism can not deal this issue.

    The EMAC DMA may run into suspend status and RX FIFO go into FULL status in some special situation, and then the EMAC can not resume to normal mode, according to the manual of BF60x, it should be resumed, but we do the operation just like the manual said, it does not work. This is the root issue I want to resolve, how can I deal this issue?

  • Hi LiLongFei,


    As you can see below, nothing special is done in our gemac drivers when RU bit is set, and we haven’t seen this issue before. Some customers have run Iperf, which sends burst traffic to DSP, and these drivers were able to handle it without any issues.

    Regards,
    Divya.P

  • Another method can reproduce this issue. Maybe you can try to make a test in your development board to check if the same phenomenon happened in your board.

    Do debug operation, when board run normally, suspend the debug running, then use a tool to do packet filling for a while (maybe you can do this 1 minute), then re-run the debug, in this case, the network will not available anymore.

    Check the EMAC DMA status, it is in RU status.

  • Hi LiLongFei,


    Thank you for sharing the procedures to replicate the issue.


    It appears that you are experiencing this issue with the custom board. So if possible, could you please share a simple project with us that simulates your issue in EZkit? This would greatly help us in providing better assistance to you.


    Regards,
    Divya.P

  • Hello Divya

    I do not have a simple project which can run in development board, this issue is found in our device which used BF607 and the source code is not allowed to share out. So here I hope you can make a test in your development board using the driver you mentioned above. By the way, our project use UCOS-II.