K64 ENET, BABT flag getting set

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K64 ENET, BABT flag getting set

810 Views
raymondwhite
Contributor III

Hello

I am using a FRDM-K64 eval board as a starting point, developing a baremetal project under KDS. I have ported my old Coldfire FEC driver code to the Kinetis ENET and modified it as appears to be necessary.

I am using the "legacy FEC" buffer descriptors. I can transmit one packet at a time without any problems. However when I send (say) five packets, I only see one packet on my Ethernet sniffer. The BABT flag is getting set in the ENET_EIR register. It seems like all the frames are getting appended into one oversized packet.

And, YES, I am setting the L bit ("last in frame") for each buffer descriptor, there are plenty of buffer descriptors in the ring, the W (wrap) and R (ready) bits seem to be working fine, the DBSWP bit is set, and I am not trying to use DMA.

Has anyone else seen a similar issue? If so, how did you resolve it?

Thanks

Tags (4)
0 Kudos
2 Replies

492 Views
raymondwhite
Contributor III

OK... so basically as Mark suggested there was an "endianness" issue. However, it occurred in one of the calculations upstream in my UDP layer which caused the ENET packets to be improperly sized.

0 Kudos

492 Views
mjbcswitzerland
Specialist V

Hi Raymond

I have never seen a BABT error (if such errors do occur the FEC needs to be reset to continue). I also ported Coldfire FEC drivers from the uTasker Coldfire project to the Kinetis project and when the legacy Buffer Descriptor mode is used there weren't any compatibility issues. The extended mode is however of course advisable since it allows greater performance due to IP check sum offloading.

Do check the endianness of the buffer descriptors since this can be set to descriptor byte swapping mode to be natively big or little endian; be careful that the bits are in the correct locations.

When using the K64 with cache enabled it is necessary to apply the errata e6358 - this is not listed in the K64 errata but can be found in early K60s, for example. If not, the Tx will often stop sending - but only for one frame and will then be triggered again as soon as another frame has been prepared in any other buffer descriptor (but wouldn't explain why you have multiple BDs not sending).

Although unlikely, ensure that you never queue a BD with a frame length of zero because this will stop the complete chain from working.

Finally, check the ownership of the BDs to see how many have actually been sent and whether some are waiting for something (or have stalled due to an error).

If you don't find a solution there are Coldfire and Kintetis (ported as directly as directly as possible form the CF to K) for comparison at http://www.utasker.com/index.html

[including legacy and enhanced BD options].

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market