Problem with TxDescriptors on at91sam7x512

Kernel
1

fanlex wrote on Friday, October 03, 2008:

Hello,

With a configuration where ethernet transmissions are fast enough (rom data sent with NETCONN_NOCOPY option) I have sometimes a problem of Txdescriptors not available, and all the transmit process is blocked when calling lEMACSend.

After having set several breakpoints, I found that the EMAC TBQP register, which must point on the next free tx descriptor entry after a transmission has been completed, and should correspond to the value of uxNextBufferToClear in function vClearEMACTxBuffer, was sometimes 2 descriptors entries forward, and when vClearEMACTxBuffer is called, the ‘buffused’ bit of descriptor pointed by uxNextBufferToClear  is clear (thus the descriptors are not cleared if they were chained)

where can be the problem ? is it possible that the EMAC has a problem ? or maybe the is a synchronization problem between tx interrupt and tx preparation in lEMACSend ?

thanks for helping…
Jean-Luc

2

rtel wrote on Friday, October 03, 2008:

Its been a while since I looked at that driver.  From memory I don’t think it handles things like overflow events.  Check the ISR that handles the Ethernet to see which interrupts are enabled and which not.  You will probably have to enabled the over/underflow interrupts and handle the errors accordingly.

Regards.

3

fanlex wrote on Friday, October 03, 2008:

Ok,
thanks for the reply.
I’m working on it with the debugger right now, trying to find a new way of handling end of buffers transmission. the behavior of DMA is not so simple.
I’m wondering why underruns can happen on transmissions … lazy DMA or silicium problem ?

regards

4

fanlex wrote on Sunday, October 05, 2008:

Hi Richard,

I have found the problem, and the solution too, for the trouble with txDescriptors.
Underrun error normally never should happen, but they do because the send function (lEMACSend) has not been optimized for that.

I take a simple example : a buffer is transmitting, and during this time lEMACSend is called for another transmission of 2 consecutive buffers.
the ‘BuffUsed’ bit of the first buffer is cleared, then, before the second buffer and descriptor  has been setup (‘Lastbuf’ may still be cleared and buffused may be set) the preceeding transmissions finishes, and the DMA picks up the first buffer of the second transmission, then the second, but this one is not complete. at that time we get an underrun error because the DMA has not found a correct second buffer.

To avoid this, the solution is to keep the ‘buffUsed’ bit of the first buffer to transmit set, and clear it only after having filled all the descriptors, just before setting AT91C_EMAC_TSTART.
I have modified SAM7_EMAC.C file and SAM7_EMAC_ISR.C accordingly, and after several tests, it appears to work perfectly.

I think that it would be important to make these modifications in the next release of FreeRTOS, since if such a problem occurs, further transmissions may be blocked, with txdescriptors busy.

In case of a transmit error, the descriptor pointer is reset to the beginning of table, however uxTxBufferIndex and uxNextBufferToClear are pointing on invalid descriptors. There is an action to take to reset all the descriptors and indexes in case of such error. This is made in lEMACSend too, with a flag set in interrupt routine.

I would be happy to share these modifications, where can I send my files ?

regards,
Jean-Luc

5

rtel wrote on Sunday, October 05, 2008:

Thanks for taking the time to provide this information.  I would be grateful if you could send the changes to r (dot) barry [at] freertos.org.

Regards.

6

fanlex wrote on Sunday, October 05, 2008:

ok, done.

7

luca79altoona wrote on Thursday, May 05, 2011:

Hello,
I have the same problem in my project.
Someone is kind enough to share these changes?

Thanks a lot, Luca

8

rtel wrote on Thursday, May 05, 2011:

I have various driver updates that have been sent to me over time.  If you contact me directly I can send them to you, but I cannot vouch for them in any way as I have not tried them myself.  You can find contact details here:
http://www.freertos.org/RTOS-contact-and-support.html

Regards.