STM32F4 lwip dropping packets?

[Charles Yarnold]

Posted on January 08, 2017 at 21:24

Hello all,

I'm currently working on a bridge that takes in artnet packets (theatrical lighting control) and spits it out as data for ws8212 leds.

I've got working code setup and running on an olimex stm32-E407 dev board, a copy of this can be found in this repo: 

https://github.com/solexious/dometroller

 (config generated with stm32cubemx)

My current issue is that if I send more than 9 packets at once (target is 16 packets, one for each output) then any over the first 9 seem to have a high chance of getting dropped. Artnet is UDP and fits into a 530 byte packet. (for testing I send all 16 from my pc at once, then wait 1000ms before doing the same, ideally when all is working the stm32f4 should be able to process 16 packets sent at once up to 44 times a second, this currently works fine if I restrict myself to 9 packets 44 times a second)

I'm not sure if this is definitely the packets getting dropped, but it seems that way. I'm not sure if this is a memory allocation issue with lwip, or not being able to keep up with the speed of 16 packets all at once. Any pointers for what to troubleshoot or fixes I can try would be very much appreciated.

Best,

Charles

[Charles Yarnold]

Posted on January 09, 2017 at 01:16

So I've fixed it, but I'm not sure yet of the repercussions of the fix or how to set this within stm32cubemx (or add an override that won't get wiped by it).

On a hunch I was poking around the code and found this in stm32f4xx_hal_conf.h

/* Definition of the Ethernet driver buffers size and count */

#define ETH_RX_BUF_SIZE ETH_MAX_PACKET_SIZE /* buffer size for receive */#define ETH_TX_BUF_SIZE ETH_MAX_PACKET_SIZE /* buffer size for transmit */#define ETH_RXBUFNB ((uint32_t)4U) /* 4 Rx buffers of size ETH_RX_BUF_SIZE */#define ETH_TXBUFNB ((uint32_t)4U) /* 4 Tx buffers of size ETH_TX_BUF_SIZE */

On that hunch I changed ETH_RXBFNB to 16 and now I have no issues!

But I thought everything to do with buffers were handled within the lwip options? As this is just below defunct MAC address setting code I thought it was old code, but it seems to be still something controlling buffers.

Can anyone shed a light on this? Will setting the value that high have any big knock on effects? How should work out its best value? (currently just setting it to how many packets I expect in one burst)

I also can't find this value to set within stm32cubemx, anyone know where it is? Or where the best place would be to override the built in define?

Cheers

Charles

[Charles Yarnold]

Posted on January 15, 2017 at 08:39

Any ideas? Still looking to find the correct way to customise ETH_RXBUFNB in stm32cubemx, or failing that the correct way to redefine it in my code. I've already been caught out by stm32cubemx resetting it to 4 and causing bugs.

Thanks

Charles

[Imen.D]

Posted on January 23, 2017 at 18:37

Dear

Yarnold.Charles

,

I forward your issue to our CubeMx team forreview and will come back to you as soon as possible.

Regards

Imen

[waclawek.jan]

Posted on January 23, 2017 at 20:32

 ,

 ,

Charles,

I don't Cube but this appears very much like the old SPL-based implementation. There, the ETH's DMA fills/empties a set of buffers defined by those ♯ defines, and when lwip is invoked, it copies data from/to these buffers to/from its own buffers.

These ♯ defines are to be tuned by the user according to his needs and the speed of processing the incoming data by lwip and the upper-level user code.

As I said I don't Cube but as far as my limited understanding of it goes, stm32f4xx_hal_conf.h is exactly the place to change these ♯ defines, as they are intended to override the default ones in stm32f4xx_hal_eth.h.

stm32f4xx_hal_eth.h:

/* Ethernet driver receive buffers are organized in a chained linked-list, when

 ,

 , , , an ethernet packet is received, the Rx-DMA will transfer the packet from RxFIFO

 ,

 , , , to the driver receive buffers memory.

 ,

 ,

 , , , Depending on the size of the received ethernet packet and the size of

 ,

 , , , each ethernet driver receive buffer, the received packet can take one or more

 ,

 , , , ethernet driver receive buffer.

 ,

 ,

 , , , In below are defined the size of one ethernet driver receive buffer ETH_RX_BUF_SIZE

 ,

 , , , and the total count of the driver receive buffers ETH_RXBUFNB.

 ,

 ,

 , , , The configured value for ETH_RX_BUF_SIZE and ETH_RXBUFNB are only provided as

 ,

 , , , example, they can be reconfigured in the application layer to fit the application

 ,

 , , , needs */

(same comment for _TX_ there)

You can't expect everything to be prechewed by CubeMX. You are supposed to study the documentation, and, if there's lack of it, the sources.

JW