I am interested in further details regarding the driver problem you
have had. I think I also have a MAC driver problem.
It looks like the MAC stops sending frames suddenly and this is
causing the lwip stack to deadlock while waiting to TX DONE IRQ.
I managed to force tx restart on the MAC and this "fix" the deadlock
but with a big performance penalty, so it's is not a real solution.
I use a TALITY MAC driver.
Please let me know your experience with your MAC driver.
The problem with the MAC I use is on the Rx Interrupt side since I don't
use Tx interrupt.
The KSZ8841 has a MAC with a Rx FIFO wich can contain several packets.
When a received packet matches all filter conditions, it is transfered
into the fifo and an interrupt is generated.
My interrupt handler only signals a semaphore.
My Rx task waits on this same semaphore, reads Interrupt status and
clears interrupt status. If Rx is signaled in Interrupt status, then the
packet is read from Rx FIFO.
The problem arises when 2 or more Rx packets are stored in Rx FIFO
before Rx task can react to interrupts (thru semaphore).
For example :
- One packet is stored in Rx FIFO, an interrupt is trigered and the
semaphore is signaled.
- Another packet is stored in Rx FIFO, another interrupt is trigered and
the semaphore is signaled again.
- Rx task gets the semaphore, reads the interrupt status, clears the
interrupt status and reads the packet fron the Rx FIFO.
- Rx task gets the semaphore again reads the interrupt status and... do
nothing since the interrupt status does not signal a Rx packet event.
I expected the interrupt status flag to be still signaling a Rx packet
in FIFO since a Rx packet IS in the FIFO.
Now, if, say, 10 seconds later a new packet is stored in the Rx FIFO,
all the process executes well but... reads the packet that has been
received 10 seconds earlier. The new received packet will be read when
another packet is received.
This way, a ping response can be sent seconds after the request.
Lwip is not faulty.
Nicolas
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
