Content originally posted in LPCWare by pierre on Sat Sep 20 07:33:05 MST 2014
Hello,
I have used MAC_TS_TSENA and MAC_TS_TSENAL but not your other flags. Maybe it is those flags that cause the problems.
I have now switched the project to be entirely USB, so I have dropped Ethernet, so don't ask me to compile some stuff and/or do some tests.
However, I may have a solution for you :
My code communicates with the Ethernet driver using two FIFOs. Those FIFOs contain packet descriptors (not DMA descriptors). Whatever code is at the other end of the FIFO doesn't know about the internal workings of the MAC, it sends a Packet* in a FIFO and that's it. You can use queues from the OS, whatever.
The RX interrupt allocates buffers from a pool, takes DMA descriptors from a ring, and keeps the DMA descriptor queue full at all times, waiting for packets.
When the RX DMA receives a completed packet, it tries to push it in the FIFO so the application can read it later. However, if the FIFO is full, because the application is too busy to read from it, it drops the packet and recycles the buffer and DMA descriptors.
It is impossible to run out of descriptors this way. It is possible to run out of buffers, if the FIFO is too large. Therefore the FIFO must be small, and the number of available buffers large enough to fill the FIFO, RX/TX rings, plus all the buffers which may be hogged somewhere in the application code.
The performance of this chip is so high it's ridiculous. Even with a quad core linux PC sending 1 byte packets at full wire speed, there were no drops.
Note, I have set this bit :
DMA_OP_MODE
Disable flushing of received frames
When this bit is set, the RxDMA does not flush any frames due to the unavailability of
receive descriptors/buffers as it does normally when this bit is reset. (See).
Check it... who knows...