I’m porting a MQTT client program from nRF52840 (using WIZnet 5500) to LPC1768 (using internal EMAC with DP83848 PHY). However, nothing relating to EthernetInterface seems to work.
I even testing the bare minimal example code from the EthernetInterface API doc page. The only thing I change is using SEGGER RTT for printing the debug messages instead of standard UART stdio. Apparently, the code doesn’t even return from
net.connect() call, so I tried instrumenting the heck off the call and it’s childs with debug messages and tracing what’s the last call to fails.
First problem is that the call to
LWIPInterface.cpp never returns. It stuck in the semihost routine from default
mbed_interface.c. Overriding the function with default MAC address (just like other targets) apparently solve the problem.
Second problem is that the calls to
osDelay() in various functions in
lpc_phy_dp83848.cpp never returns. Hmm, just a simple delay so replacing it with
__NOP() loop busywait should be fine.
Next problem is that the calls to
lwip_system_arch.c never returns. More specifically, the call to
__svcSemaphoreAcquire() from one of it’s codepath never returns. My tracing stops there. I don’t know what it is, and my IDE don’t know where it came from either. I also thinking that such low level OS function should be extensively proven already and should not fail. So there’s probably something wrong with how the OS and/or target is set up. What I did wrong here? Going back and forth from os5.14 and os6 doesn’t seems to make any meaningful difference, and I don’t think I have the time to check any earlier versions.
There’s also a possibility that the semaphores are acquired by someone else, but this is pretty much still initialization stage, it should be fairly straightforward .