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!