Bug in cubemx IDE LWIP + freertos on NUCLEO f429ZI

[dieter 123]

Hi

I setup a new cube project using cubeIDE for NUCLEO f429ZI.

• iselected the NUCLEO f429ZI
• I added LWIP + no DHCP
• I added Freertos CMSIS V2
• I compiled the code.

Problem 1: ping was not working.

I solved it by increasing the stacksize of default task to1024 bytes.

With this I could Ping the board.

Problem 2: after some minute ping would no longer work.

My code would hang here: xQueueSemaphoreTake::::-> configASSERT( pxQueue->uxItemSize == 0 );

I solved this by giving the defalt task "osPriorityAboveNormal"

Atleast it didnt hang for the last 20 minutes.

is this a bug, or am I missing something?

I also attached my cube ioc file.

Would be nice if some could help out.

[Dave Nadler]

@Piranha​ - No, I've got a problem on F413 where DMA2 just stops working, when I'm running four streams continuously.

Sometimes it runs for many hours, sometimes only a few seconds, then hangs.

For now I'm resetting the whole thing via a watchdog but its rather disturbing...

Ethernet stuff is working reasonably (LwIP 2.1.2) though I will apply all your fixes.

[Skarel]

Hello All,

Just wanted to say that I have/had the same problem.

I implemented the the heap work around/solution provided by Dave Nadler (see link above to a different problem) ​ http://www.nadler.com/embedded/newlibAndFreeRTOS.html

But, I had no luck. I then changed from CMSISv2 to (the old?) CMSISv1, and my basic solution FreeRTOS + Dave's workaround + LWIP + 2 of my own tasks which printf(",") and printf(".") before sleeping for hundreds of milliseconds, and this has been running for days.

If anyone wants to look at it, I have attache the project folder as a zip file.

If anyone has found a working solution using CMSISv2, please post it if you have the time.

Thanks.

Karel

[VB.2]

I'm having this same problem on the h745zi using the hal and autogenerated files. I've gotten the eth working by using dave's heap_newlib implementation. But now I block on

configASSERT( !( ( pvItemToQueue == NULL ) && ( pxQueue->uxItemSize != ( UBaseType_t ) 0U ) ) );

Interestingly, this only happens after I exit a udp callback. I'm working on a boot loader with a tftp server (modifying this example), the start request callback successfully triggers, sets a new callback function (the write request callback), which gets triggered on the first request, it completes successfully, sends an ack packet back, and then returns. From this point on I don't see any udp messages from the stm board, and it fails to trigger the callback because the debugger shows it blocking on the line I mentioned above.

I have confirmed that it is because `pxQueue->uxItemSize` is not 0. I'm assuming that it is because the queue got corrupted like DBurr mentioned above. `pvItemToQueue` is explicitly passed in as NULL, and it is actually NULL.

I've tried increasing the priority of the task as well as the stack size, but neither have fixed it. Has anyone figured out the fundamental issue here?

[VB.2]

oops. I missed Karel's response above. That worked! using CMSIS_OS v1 fixed my issue!

[GAuye]

Someone told me, if you work with a OS you will have two problems, your own problem plus the OS... and for me is totally true... I have the same problem, I compiled with CMSIS_V1 and seems that ping is working, but TCP connection not... I don't want to spend days understanding lwip, CMSIS and FreeRTOS... Does anybody solve this problem using CMSIS_V2? (now in 2024) Thank you!!!

[hilalinan]

Do you spesifically have to use the CMSIS_V2?

I have been struggling for weeks about this topic and i finally got a working lwip freertos tcp/ip example but with CMSIS_V1.

I dont know if the problem was directly about V1 vs V2 because i faced lots of them so i can not say v1 will solve all of your problems but give it a try 

[GAuye]

Hi Hilalinam, no, it is not mandatory to use CMSIS_V2, also I prefer to use raw FreeRTOS but, the lwip example I started from use CMSIS so it is easy...

Regarding your suggestion, yes, after moving to CMSIS_V1, ping was working but TCP not.... After adjusted the memory size of my tcp_thread to DEFAULT_THREAD_STACKSIZE (1024), everything is working fine, so thanks for your advice. 

I don't want to spend days understanding why, but if anybody has studied this issue, will be good to share the answer in the community... I'm willing to work with OS, but things like this make me a little be worry about using FreeRTOS and CMSIS... I'm working in a industrial remote Modbus device and perhaps is time to move to baremetal solution...

Thanks again!!!