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.

[Piranha]

Changing priority can't fix wrong code. It only hides the bugs.

ST's ethernetif.c and HAL ETH driver are full of bugs and broken beyond repair, and I'm not sure about sys_arch.c and CMSIS-RTOS wrapper also...

[Dave Nadler]

@Piranha​ - For what its worth, I'm having good luck with F4 driver and LwIP 2.1.2 (unlike F7 drivers which are reported spectacularly buggy)...

@dieter 123​ - Absolutely agree priority isn't the root problem.

Hope that helps,

Best Regards, Dave

[dieter 123]

Ok, in which version did these problems come in?

I am happy to roll back.

STM32Cube_FW_F4_V1.18.0 used to be stable. Anything newer than that?

[Dave Nadler]

@DBurr​ , @dieter 123​ - Have you got LwIP working OK?

If not, perhaps it's this problem: https://community.st.com/s/question/0D50X0000BB1eL7SQJ/bug-cubemx-freertos-projects-corrupt-memory

@Piranha​ - I think you posted about STM bugs in F7 ethernetif.c and HAL ETH driver, but do you know of problems in the F4 versions as well?

Thanks!

Best Regards, Dave

[DBurr]

@Dave Nadler​ Yes, I did finally get LwIP and FreeRTOS working correctly. I have 2 separate threads that use LwIP and I failed to use LwIP "sys_thread_new" function for initialising these threads. I also found that I'm using a lot of stack in my threads and it's because of my use of printf. I plan to remove printf and replace with a lighter weight version - your article about using newlib correctly was definitely helpful!

[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

[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 

[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!