Skip to main content
scaprile
scaprile
Associate III
September 15, 2022
Solved

Developing on an STM32CubeIDE project with lwIP + FreeRTOS

  • September 15, 2022
  • 3 replies
  • 4960 views

Is there a guide to follow ? How is memory assigned to lwIP ? Is it running on a separate task ?

I'm running a Mongoose demo which requires a big stack. I'm using the default task created by CubeIDE which just inits lwIP and goes to sleep on an infinite loop. Here I placed my app code.

Setting a stack of 2048 words is not enough for this app, but if I go higher then lwIP stops working (DHCP won't start properly, my app starts after DHCP has acquired an IP). Should I use a separate task ? Why ?

I'll be happy to get some pointers, though I'll dig lwipopts and the source code if necessary, I hope it is not; this is just a demo...

This topic has been closed for replies.
Best answer by scaprile

MX_LWIP_Init() creates a new thread for lwIP and assigns a stack of configMINIMAL_STACK_SIZE *2 for it:

(gnetif is a global), then it calls the DHCP start function (from the default thread)

So, the stack size affecting lwIP is the one set in Config parameters -> MINIMAL_STACK_SIZE, and they already accounted for a magical times 2; maybe to guarantee 256 words minimal.

Memory allocation defaults to "dynamic", so each task stack is alloc'ed from the heap. To get a higher task stack size, FreeRTOS heap size must be increased. It defaulted to 15360 bytes, so on a 320KB RAM MCU, both stacks and the app malloc's were colliding on a 15K room...

If you will be using the sockets API, it uses the netconn API. There is no way of configuring the number of connections in the wizard, so you have to add it to the preprocessor symbols or manually modify lwipopts.h

MEMP_NUM_NETCONN

Default is 4, so if you need more, change it

There are 3 tasks: one for the core, one to get data out of the MAC and one to poll the link status. The receive task waits on a semaphore that is released by the rx complete IRQ and memory allocation is thread-safe using mutex. Data is passed to the core thread using an RTOS mailbox

3 replies

Piranha
Piranha
Principal III
September 15, 2022

https://lwip.fandom.com/wiki/LwIP_Wiki

https://www.nongnu.org/lwip/2_1_x/

For embedded software 8KB of stack memory is huge. Are you sure it actually requires it, or are you just guessing?

scaprile
scaprileAuthor
Associate III
September 15, 2022

It uses lots of stack (vendor suggests minimum 8KB), can run tests on other stable environments to determine but since the app log reports allocation problems and this micro has 320KB RAM I would rather save some time.

I'm familiar with lwIP on bare metal, however, I don't know how ST runs it on FreeRTOS

scaprile
scaprileAuthorAnswer
Associate III
September 16, 2022

MX_LWIP_Init() creates a new thread for lwIP and assigns a stack of configMINIMAL_STACK_SIZE *2 for it:

(gnetif is a global), then it calls the DHCP start function (from the default thread)

So, the stack size affecting lwIP is the one set in Config parameters -> MINIMAL_STACK_SIZE, and they already accounted for a magical times 2; maybe to guarantee 256 words minimal.

Memory allocation defaults to "dynamic", so each task stack is alloc'ed from the heap. To get a higher task stack size, FreeRTOS heap size must be increased. It defaulted to 15360 bytes, so on a 320KB RAM MCU, both stacks and the app malloc's were colliding on a 15K room...

If you will be using the sockets API, it uses the netconn API. There is no way of configuring the number of connections in the wizard, so you have to add it to the preprocessor symbols or manually modify lwipopts.h

MEMP_NUM_NETCONN

Default is 4, so if you need more, change it

There are 3 tasks: one for the core, one to get data out of the MAC and one to poll the link status. The receive task waits on a semaphore that is released by the rx complete IRQ and memory allocation is thread-safe using mutex. Data is passed to the core thread using an RTOS mailbox

Piranha
Piranha
Principal III
September 17, 2022

The tcpip_init() function creates a lwIP core thread internally. Also take a note that the MX_LWIP_Init() and the ethernet_link_thread() functions are broken because they break the lwIP stack's multi-threading rules. That can cause an unpredictable corruption and behavior.

scaprile
scaprileAuthor
Associate III
September 17, 2022

I'm experiencing something weird, will start by looking there, thanks a lot

Terms & ConditionsAccessibility statement