cancel
Showing results for 
Search instead for 
Did you mean: 

ETH RX debugging �? Threads not started

Michael R
Associate
Posted on January 10, 2018 at 21:55

My development hardware is the Olimex P107 board (Rev D: STM32F107VCT6 MCU, LAN8710 PHY).

DHCP and ping in a bare lwIP example are working fine. Now I want to combine FreeRTOS and lwIP. I'm using the latest STM32CubeMX to generate the code templates (i.e. with lwIP 2.0). I can see that the Ethernet link is properly established, and that DHCP request packets are sent from time to time. The DHCP server is responding as expected, but the IP is never accepted by lwIP. In fact, there is no reaction whatsoever to any incoming packet. Therefore, my assumption

at the moment is that for some reason, incoming packets are not passed on to lwIP.

I'm already calling dhcp_fine_tmr and dhcp_coarse_tmr as required.

After debugging a bit more, I find something very strange: I can have one of two error modes, the root cause is the same.

Case 1: The ethernetif_input thread is not running.

Case 2: tcpip_thread thread is not running.

In both cases, the function call (osThreadDef+osThreadCreate, or sys_thread_new, which ends in the same calls) is executed, but the thread just doesn't start!

The error modes do not alternate when I have a fixed executable. But it can happen that I make unrelated changes that give a new executable that fails the other way.

Is there any setting that could explain such behaviour?

Thanks.

#freertos #lwip*
1 REPLY 1
Michael R
Associate
Posted on January 11, 2018 at 15:42

I remember that I read something about FreeRTOS thread creation itself not being threadsafe. Is this really the case?

So it's not a fix, but a workaround: Putting a vDelay(1000) in front of one the calls that create a thread lets them both start and do their work.

I now have working DHCP and ping!

Still the question is: Why is this required?