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.

TM4C129x EMAC problems

Other Parts Discussed in Thread: TM4C129XNCZAD

I'm having problems getting the EMAC Ethernet peripheral to work. I'm using a DK-TM4C129X board with unqualified XM4Cxxx part on it. I'm using the internal PHY.

I think I found an error in the Data Sheet and I have made some progress.

It appears that the following statement on page 1608 of "Tiva TM4C129XNCZAD Microcontroller Data Sheet" is not true.

Quote from Data Sheet:

TBS1: Transmit Buffer 1 Size
These bits indicate the First Data Buffer byte size. If this field is 0, the DMA ignores this buffer and uses Buffer
2 or next descriptor depending on the value of TCH (Bit 24).

End Quote.

I cannot make that work at all. I just get FBI errors (fatal bus error) and AE field is 3 (Error during TX DMA Read Data access). This is when I make buffer 1 size 0 to try to use only 2nd buffer. I suspect the same is true of RX descriptors.

I tried using just buffer 1 with buffer 2 size 0. I also tried using chained TX descriptors. In both cases I don't get FBI errors any more. The transmit DMA seems to be working - sort of. It activates interrupts at completion and moves the hw TX DMA descriptor pointer as expected. There appears to be no output from the PHY so I cannot see any packets on the wire. I have not tested if the TX DMA engine wraps at the end of the TX descriptor list.

The TCP/IP stack that I use breaks a transmit packet up into 2 or 3 or more non-contiguous buffers. The first buffer has 14 bytes in it (size of ethernet header, I think). The remaining buffer(s) have the rest of the packet. I create TX descriptors to match these buffers.

The receiver DMA can receive packets okay. It signals interrupts on completion and I can retrieve the packets and I can give ownership of descriptor back to DMA. But it has a major problem. It will not wrap back to the base of the RX descriptor ring. I have tried using chained descriptors and using the RER bit in the final descriptor (and also tried with both together) but it just won't wrap back even when it owns the descriptors at the start of the ring. To debug, I read EMAC_HOSRXDESC register and it shows that the DMA did not wrap to RX descriptor base.

When the RX DMA reaches the end of the descriptor list, it is still running and continues to give interrupts that say RX overflow every time a packet is received. Of course it doesn't actually receive the packet because it does not have a place for it because it did not wrap back to the start of the descriptors.

I'm using my own routines to manage the EMAC and the GCC tool-chain for building. I'm using only "normal" DMA descriptors and both descriptors and buffers are in SRAM. Both RX and TX buffers in the descriptors (only using buffer 1 in each descriptor) is 128 bytes in size.

I notice that all the examples use the enhanced/extended DMA descriptors instead of the normal descriptors. I don't know if that is the cause of my problems. I notice also that the FS, LS, and other DMA control bits move around in the descriptors based on using normal or extended descriptors. That seems odd to me.

Thanks for any help you can provide.

  • Okay, I got receiver DMA to wrap at end of descriptors. The data sheet is incorrect about location of RCH bit in RDES1 descriptor word. Probably the data sheet is incorrect about RER bit also but I have not tested that.

    Need Engs at TI to double-check layout of "normal" descriptors (and maybe all descriptors?).in data sheet.

  • Okay, I'm seeing signs of life from the transmitter now. Definitely appears to be a mix-up in the data sheet regarding the locations of bit-fields in the "normal" descriptors for both transmitter and receiver.

  • Hi Daniel,

    The data sheet matches the source documentation, so I believe it is correct.

    All the code in TivaWare uses the alternate descriptor layout (which allows us to use PTPD without having to worry about changing descriptor types depending upon the options applications want to enable) rather than the smaller “normal” descriptor.

    The #defines in emac.h are all related EXCLUSIVELY to the enhanced descriptor format. If you are using normal descriptors and manipulating them using #defines found in emac.h, problems such as you have seen can happen.  DriverLib only supports enhanced descriptors so you'll have to write your own code to manipulate the descriptors if you want to use the smaller descriptor layout instead.

    Regards,

    Sue

  • Hi Sue,

    Thanks for your reply. I'm using my own routines to manage the EMAC and EPHY peripherals. I'm not using TI headers, sources, or libraries.

    Respectfully, I'll stand by my assertation that the data sheet is incorrect about the locations of some of the bit-fields in the normal descriptors. I have evidence in the form of working code for normal descriptors.

    I have working code and I am no longer blocked by this problem. This issue can be closed.

    Thanks again.

  • Hi Daniel,

    I'm glad you got it working.  I can definitely take your concerns back to the designers and have them double check the documentation.  Could you please summarize the items that you believe are incorrect so I can make sure they all get looked at?

    Thanks,

    Sue

  • Hi Daniel,

    In addition, the designer asks if you can please send the relevant code snippets that didn't work as well as the ones that did, that would greatly assist us in tracking this issue down.

    Thanks,

    Sue

  • Sue,

    Sorry, but this is "work made for hire" so I am unable to post any source code here. I just don't own it.

    In previous posts I did call out some of the bits in the EMAC descriptors that I think are described erroneously in the data sheet. In particular have your designer review the bits in "normal" TX and RX descriptors that delineate the Ethernet frames (FS, LS bits) and descriptor rings (TER, RER bits). I could not get the EMAC to work correctly with normal descriptors using the documented locations of those bits.

    Thanks.

  • Thanks Daniel,

    I appreciate whatever help you can give us.  The more specific the better.  I did pull the bits out that you mentioned in your previous posts, but I was hoping you could provide a complete list.

    I understand your concerns about posting your code publicly.  If you are willing to share to help us track down this issue more quickly, I would appreciate it if you could email it to support_lmi@ti.com.

    Regards,

    Sue

  • Hi Daniel,

    You mentioned that you believe the FS, LS, RER, and TER bits are not shown in the correct locations.  The designer said that in looking at the RTL, he found inconsistencies with these bits.  Could you please tell me where you believe these bits are actually located to help correlate with his findings?

    We really appreciate your help.

    Thanks,

    Sue

  • These are the bits that I need to use with normal descriptors in order to make them work correctly:

    #define TM4C_EMAC_ERBD_RDES1_RER  (1 << 15) // RX End of Ring

    #define TM4C_EMAC_ETBD_TDES0_IC   (1 << 30) // Interrupt on Completion
    #define TM4C_EMAC_ETBD_TDES0_LS   (1 << 29) // Last Segment
    #define TM4C_EMAC_ETBD_TDES0_FS   (1 << 28) // First Segment
    #define TM4C_EMAC_ETBD_TDES0_TER  (1 << 21) // TX End of Ring

    Note that they are listed in the data sheet as being only for use with enhanced descriptors. These bits are all in the reserved area of normal descriptors. The corresponding bits listed in the data sheet for use with normal descriptors don't seem to work with normal descriptors. Note also that the receive FS and LS bits for normal descriptors seem okay.

    IIRC when I was using chained normal descriptors, I had to use these bits:

    #define TM4C_EMAC_ERBD_RDES1_RCH  (1 << 14) // 2nd Address Chained
    #define TM4C_EMAC_ETBD_TDES0_TCH  (1 << 20) // 2nd Address Chained

    Note these bits are also documented as only for enhanced descriptors.

    The EMAC appears to work okay using the above listed bits for enhanced descriptors in normal descriptors. Probably just data sheet that is misleading. Still, it would be nice to have this confirmed by TI and the layout of normal descriptors documented. Using bits in reserved areas of the descriptors is scary!

  • Thanks Daniel.  I appreciate all of the information. I'll pass it on to the designers and let you know what we find out.

    Regards,

    Sue

  • Hi Daniel,

    Your observations have been confirmed.  We'll get the data sheet updated for the next revision.  Thank you very much for bringing this to our attention.

    Regards,

    Sue