Post Go back to editing

EMAC DMA stuck after first transmission

Category: Software
Product Number: SC572
Software Version: CCES2.11

Hi Team,

I'm trying to get baremetal EMAC to work on a custom board equipped with an SC572 chip and a LAN83C185 (100M) Phy IC.

I've tested the physical connection for the MDIO lines with the UBoot MII utility and have written and tested the MDIO lines with a custom PHY driver in bare-metal C. The EMAC is configured such that it's using the GEMAC library provided by ADI (see photo below). I assumed that it would work with the 100M LAN83C185 chip because the SC584 EZ-KIT also has a 100M Phy IC onboard and it uses the GEMAC library too (please correct me if I'm wrong)

I have copied the EMAC test code from the POST example to a bare-metal project and managed to get it to send one single Ethernet II packet. However, the EMAC DMA register EMAC0_DMA0_STAT reads 00670445, which sets TI, TU, NIS,TS=6.

Since EMAC0_DMA0_STAT's AIS and UNF are not set, I assume it's not a buffer underflow and it's a descriptor ownership problem. What I can do to resolve this descriptor ownership problem? (or if it's a configuration problem, what is the appropriate configuration for 100M PHY IC?) 

Cheers

Parents
  • Hi,

        Are you getting any error message in the console window after DMA stuck? Or where the code stucks in the disassembly window?
        Please ensure that you are following the steps mentioned in the “EMAC Programming Model” available in the HRM.
        Can you please confirm whether the clock is configured as per the spec mentioned in the datasheet.

    Regards,
    Divya.P

  • Hi Divya,


    I'm not getting any error messages in the console window. 

    In terms of clock rate, it's using 25MHz clock for both PHY ICs as per datasheet.

    Yep, the steps mentioned in the "EMAC Programming Model" is implemented in the GEMAC driver ADI provides. Following the stack trace of the GEMAC driver, we can see that it's doing the steps described in the manual.

    ----

    Upon further investigation. We found that the first transmit descriptor doesn't have an ownership problem as the GEMAC driver correctly sets the OWN bit.
      

    Instead, after the EMAC_DMA0_TXDSC_CUR points to the first descriptor and we write to 

    we get  .

    it looks like we get some errors from the receiver side, specifically a buffer overflow and receive buffer unavailable. These error bits then gets handled by the void EMACInterruptHandler(uint32_t IID, void *pCBParm), which does the following:

    Since TU and RU bit is set, it will call the transfer_queued_bufs function. which just tries to send/receive again by setting the tx/rx poll registers.

    I'm not sure where to go from here. Since there are separate FIFO buffers for TX and RX, one can reasonably assume that a buffer overflow in the RX buffer shouldn't affect the TX buffer? or am i incorrect in that assumption?

    Please advise what I can do next to further debug this. 

    Cheers

Reply
  • Hi Divya,


    I'm not getting any error messages in the console window. 

    In terms of clock rate, it's using 25MHz clock for both PHY ICs as per datasheet.

    Yep, the steps mentioned in the "EMAC Programming Model" is implemented in the GEMAC driver ADI provides. Following the stack trace of the GEMAC driver, we can see that it's doing the steps described in the manual.

    ----

    Upon further investigation. We found that the first transmit descriptor doesn't have an ownership problem as the GEMAC driver correctly sets the OWN bit.
      

    Instead, after the EMAC_DMA0_TXDSC_CUR points to the first descriptor and we write to 

    we get  .

    it looks like we get some errors from the receiver side, specifically a buffer overflow and receive buffer unavailable. These error bits then gets handled by the void EMACInterruptHandler(uint32_t IID, void *pCBParm), which does the following:

    Since TU and RU bit is set, it will call the transfer_queued_bufs function. which just tries to send/receive again by setting the tx/rx poll registers.

    I'm not sure where to go from here. Since there are separate FIFO buffers for TX and RX, one can reasonably assume that a buffer overflow in the RX buffer shouldn't affect the TX buffer? or am i incorrect in that assumption?

    Please advise what I can do next to further debug this. 

    Cheers

Children