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...

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

@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

[DBurr]

I've found the same problem as above, after a random amount of time, usually within a few hours the same exact assert is tripped. It looks like the semaphore that is part of the CubeMX ethernet_if thread is getting corrupted. The thread's stack size is set to only 350, I'm wondering if this is the problem. Has anyone taken the time to debug this further and figure out what the problem is exactly?

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

[Piranha]

https://community.st.com/s/question/0D50X0000BOtfhnSQB

@Dave Nadler​ , the two bugs reported till now are relevant to F1, F2, F4 and F7. The next bug I will report is relevant to absolutely all STM32 series with Ethernet - the code is missing compiler and CPU memory barriers. Yes, they are needed even with MPU configuration! As a very simple quick advice - put __DMB(); just before and after accessing OWN bit. The bug report will be with more details and explanation.

Then there is an issue with MMC counter interrupts not disabled, but that will happen only after 2 billion counted frames on each counter.

lwIP related code - link status, netif up/down, DHCP - is also a total mess and most likely faulty, though I haven't looked at it thoroughly.

[Dave Nadler]

Thanks, will follow up after I sort out the DMA-hang problem here, aarrggg...

[Piranha]

Do you mean Ethernet DMA? 🙂