ethernet transmit buffer full

[mrtumnus]

I am developing a product using an MK64FN1M0VLL12 microcontroller and a two-port managed ethernet switch, SMSC's LAN9303i.  I have encountered a problem in which the ethernet driver seems to lock up after a flood of packets (ICMP/ping, in this case).  The symptom is that the transmit buffer ring appears to fill up, but gets in a state where it never gets cleaned up.  Subsequent calls to ENET_DRV_SendData fail due to the buffer being full.  I do not observe the Tx interrupt ever being triggered in this state (thus, ENET_DRV_CleanupTxBuffDescrip() is never called, which 'frees' up buffer descriptors).

The only options I can think of are:

1. Apply some band-aid by manually cleaning up the buffer descriptor ring (when? how?)
2. Increase the transmit buffer ring size.  This also seems like a band-aid that doesn't address the root problem.
3. Reset the whole driver when this state occurs (last resort)

[manfredschnell]

Hi Elliott,

I had a similar problem with K64 + KSDK2.0 and KSZ8863MLL switching ethernet phy. On a packet flood the buffer memory is filled up with incomming messages --> no memory for tx.

Please have a look at FRDM-K64F KSDK 1.3.0 tcp_echo demo bugs? and my last post according the priority of lwIPInterruptTask() an tcpip_thread().

You should to something like this in your system.

If you have further questions, don't hesitate to ask.

Best regards

Manfred

[mrtumnus]

Manfred,

Thanks very much for the quick reply.  I failed to mention that I am not using an RTOS, just a bare-metal application.  However, you raise a good point that the Rx interrupt may be firing during the handling of an outgoing frame.  I will check into disabling interrupt(s) during this time.  Do you think this might be the same issue, but on a bare-metal app?

Regards,

Elliott

[manfredschnell]

Hi Elliott,

the issue is the same, regardless of the underlaying system.

You have to take care for calling tcpip_thread() enough times in your bare-metal application.

I think it's not necessary to disable RX-IRQ. The RX driver will handle the case, when no buffer is free.

Instead I would process the already received packets.

Do you have enough memory buffers?

My application uses:

#define PBUF_POOL_SIZE          32

#define PBUF_POOL_BUFSIZE       256U

Did you rework the "ethernetif_Input()"? The original KSDK2.0 version leads to strange errors, because of an error when receiving into chained buffers. --> memory is overwritten...

Have a look on my "ethernetif_Input()" in https://community.nxp.com/thread/395104‌

Best regards

Manfred