|
I've been seeing a similar problem. I have the at91lib emac code working via interrupts (not polling, like the examples) nicely with lwip for sending, but I think there are a couple problems with the emac code with regards to receiving. Maybe these only apply to interrupt-driven usage, since the examples are all poll-based?
1. The system can get into a state where all the rx buffers are marked as owned by the emac, but an isr is never triggered by one of the sources that indicate data is ready for reading. Unscientifically, I've seen things usually work for a few (3-4) loops through the rx buffers before getting into this state. I haven't fully tracked down exactly where the transition into this state happens. The fact that I see Buffer Not Available errors triggered while in this state makes me think that new data is arriving, but an available buffer can't be gotten. Interestingly, I never see any overrun errors, only buffer not available.
2. In the EMAC_Handler(), rx error checking is done inside the block that is executed if a full frame has been received. Errors that occur in a different context (ie, Buffer Not Available) are not handled. This is obviously problematic since a frame can't be successfully received if there are no buffers available. Also, the rx callback is only triggered in the case that a full frame has been received. Since the isr status is passed back to the callback, it might want to do something with some of those error conditions, and should as such be called when an error condition arises. I've altered the code slightly to do this, so I can make a call to EMAC_Poll() from my callback when I get a Buffer Not Available interrupt.
Do any of the authors of the at91lib emac code read this forum? It would be interesting to get some input on this...
|