LPC17xx lwip driver

giusloq — Wed, 03 Apr 2019 15:35:59 GMT

I'm facing a problem with my custom board with LPC1768 MCU. I'm using Ethernet and lwip stack.

It works well many times, but now always.

I'm studying the module lpc17xx_40xx_emac.c and I found something strange. We have a number of TX descriptors configured by the preprocessor symbol LPC_NUM_BUFF_TXDESCS. Suppose it is 4. Now we have two integers, consumer and producer index (cidx and pidx). They both start at zero.

When the application produces a new frame, producer index is incremented in lpc_low_level_output().

When a frame is completely transmitted, the consumer index is automatically incremented by the MCU hw.

In lpc_low_level_output(), lpc_tx_ready() is called to read the number of free TX descriptors available. lpc_tx_ready() returns a number in the range 0..3, even if we have 4 descriptors. I think this is correct, because we can't fill all the descriptors, otherwise the wrap-around of indexes results in mathematical errors when calculating the number of free descriptors (it's a classical problem of ring buffer). We need to loose one descriptor.

At the beginning (cidx=pidx=0) it returns 3 free descriptors.

lpc_low_level_output() blocks if there aren't free descriptors (if lpc_tx_ready() returns 0). Theorically I could call lpc_low_level_output() 100 times without problems: the function blocks until previously added descriptors are serialized out on the wire.

However it seems a wrong behaviour to me. We have to call lpc_tx_reclaim() in order to free the pbufs after they are transmitted.

If the application calls lpc_low_level_output() many consecutive times without calling lpc_tx_reclaim(), it will be able to transmit the data with success (by blocking), but we finally could have some not-freed pbufs in memory.

Indeed lpc_low_level_output() saves the pbufs references in lpc_enetif->txb[] array, using the produce index as the array index. Here we could overwrite previous pbufs that are really sent but not freed.

In my application I'm facing a similar problem. The application (MQTT client over mbedTLS session) sends some data during TLS handshake. I noticed that under certain conditions, some pbufs aren't completely freed and remains in the heap. It seems this happen when many output packets are produced in short time.

I don't think the application is buggy. I can compile the same code with mingw in a Windows desktop machine and it works well. The only thing that changes is the Ethernet driver. The application and TCP/IP stack is identical.

Re: LPC17xx lwip driver

AldoG — Fri, 12 Apr 2019 22:53:23 GMT

Hello,

Please take a look to this document

[https://community.nxp.com/docs/DOC-330815]

Where it gives a brief overview of how buffers are managed in the driver and the LWIP applications

Regards,

Aldo.

Re: LPC17xx lwip driver

engineering1 — Mon, 09 Mar 2020 13:29:30 GMT

Hello,

I think I had the exact same problem.

I fixed it. Check this: https://community.nxp.com/message/1280119

Thanks,

Sébastien

topic Re: LPC17xx lwip driver in LPC Microcontrollers

LPC17xx lwip driver

Re: LPC17xx lwip driver

Re: LPC17xx lwip driver