It may explain the eventual EMAC hangs. The problem, with scratching a solution that worked in my case, can be found in my blog:
During my actual project (using an Atmel AT91SAM7X controller) I encountered a bug that also exists in the lwIP demo of FreeRTOS. I tried it and the problem really occurs. It is likely that the bug does not affect an embedded web server like the demo (in normal circumferences), but, as the the problem is in the very simple ISR, it might be found in several different projects.
The observation: if we send a fast burst of huge amount of data for a couple of seconds (with a packet generator for example), the EMAC controller stops answering and does not recover. If we do it for a minute, it surely hangs.
The reason: The data arrives faster than the controller is able to process it. So in a given moment, all the receive buffers get used in the same time. The controller does not generate RCOMP interrupts any more, it generates RXUBR interrupts only as all the buffers are used, all the used bits are set. If this interrupt is not handled in the EMAC ISR - the networking task is never signalled - the data in buffers never processed - all the buffers remain used - the controller stops receiving data.
The solution I used in my project: enable RXUBR as well. When this interrupt occurs, it is also considered as frame arrived. If fact, someone really wanted to send us something:
if (status AT91C_EMAC_RCOMP || status AT91C_EMAC_RXUBR)
/* A frame has been received, signal it */
_n_ethernet_is_frame_received = TRUE;
This will trigger data processing. By checking the ownership bits (the code should do it when it looks for the frame’s last buffer), the code can easily detect that all the buffers are used, so a data burst must have arrived. It than starts the appropriate recovery action (in my case, I simply releases all the buffers by dropping the content, until the data rate normalizes).