Hi
Using the following tools:
TouchGFX Designer 4.24.0
CubeIDE 1.16.1 and
CubeMx 6.11.0
I have attempted to build a system with ethernet capability.
I added the ethernet peripheral, LwIP compiled it without any errors, but the ethernet does not work. The router it is connected to does not "see" the MAC address and fails to assign an IP address. I have DHCP enabled.
I bolted Adam Berlinger's code into one of my projects
and that worked fine, with DHCP but the I cannot get the latest CubeMX build to work.
I have used the same board and cable that I used with Adams ethernet code for the new build so it's not the hardware.
Is the latest CubeMX build supposed to at least connect to a router and allow a ping test or do I have to do something else. The touchGFX code is working fine.
To be quite frank I find the ST Ethernet firmware and builds to be a nightmare. You basically have to be an experienced network engineer first to understand the jargon. SMTP, DHCP etc which is never spelled out in full in the cube help panel and secondly to work your way through the code which is like spaghetti to find out what is going wrong. LwIP is very clever, but its documentation is a joke considering how widely it is used. Compared to a system like FreeRTOS which has excellent documentation, a vibrant forum and heap and heaps (pardon the pun) of examples, LwIP is more like a hackers bad dream. Its been around for over twenty years yet the documentation is sparse to say the least.
The Wiki content for the socket API is just a regurgitation of the header file for the macro or function. Here is the entry for setsocketopt:
Now I'm guessing that setsockopt sets some options for the socket the application programmer is trying to instantiate. But it doesn't explain that, or what the various macro parameters do and what valid inputs they can be.
I am guessing that s is the socket handle, but what the rest of them are is beyond me. An application Programming Interface needs a lot more than code it needs an explanation of what the function does, when you should use it and what its parameters are.
Surely someone in ST could come up with some code that would provide simple things like ubiquitous for ethernet such as DHCP, mDNS, SNTP and a simple socket interface without the applications programmer needing to do a PhD in advanced network engineering. The hardware works fine, but the software...
From my little rant the perceptive among you probably sense I am just a little frustrated. I reckon I have spent more time trying to get ethernet to work than I have spent on all the other peripherals combined.
Am I being silly, am I missing something? What do others think?
Kind regards
Rob
1 ACCEPTED SOLUTION
Accepted Solutions
Hi Again ST
I ran traced the program flow of MX_LWIP_Init() to determine where things were going wrong. It didn't take long to find as the error occurs in the tcpip_init( NULL, NULL ); function in the tcpip.c file function lwip_init(void) and more precisely in the udp_init() function. This may be found in file udp,c,
/**
* Initialize this module.
*/
#pragma GCC push_options
#pragma GCC optimize ("O0")
void udp_init(void)
{
#ifdef LWIP_RAND
uint32_t randNo = LWIP_RAND(); /* <== Fails in the rand function rjg debug */
udp_port = UDP_ENSURE_LOCAL_PORT_RANGE(LWIP_RAND());
#endif /* LWIP_RAND */
}
#pragma GCC pop_options
The call to the stdlib, rand() function fails at the assert function:
rand:
90033524: ldr r3, [pc, #88] @ (0x90033580 <rand+92>)
90033526: push {r4, lr}
90033528: ldr r4, [r3, #0]
9003352a: ldr r3, [r4, #48] @ 0x30
9003352c: cbnz r3, 0x9003355c <rand+56>
9003352e: movs r0, #24
90033530: bl 0x900333a8 <malloc>
90033534: mov r2, r0
90033536: str r0, [r4, #48] @ 0x30
90033538: cbnz r0, 0x90033544 <rand+32>
9003353a: ldr r3, [pc, #72] @ (0x90033584 <rand+96>)
9003353c: ldr r0, [pc, #72] @ (0x90033588 <rand+100>)
9003353e: movs r1, #82 @ 0x52
90033540: bl 0x90033360 <__assert_func> ;<== Fails here program hangs no hard fault
90033544: ldr r1, [pc, #68] @ (0x9003358c <rand+104>)
90033546: ldr r3, [pc, #72] @ (0x90033590 <rand+108>)
90033548: strd r1, r3, [r0]
9003354c: ldr r3, [pc, #68] @ (0x90033594 <rand+112>)
9003354e: str r3, [r0, #8]
90033550: movs r3, #11
90033552: strh r3, [r0, #12]
The program ends in the while(1) loop in syscalls
void _exit (int status)
{
_kill(status, -1);
while (1) {} /* Make sure we hang here */
}
This is weird so I tried the rand function in main.c. and it worked.
I call the MX_LWIP_Init from the default task that i renamed monitorTask so I checked the stack assignment, it was only 128 words so I increased it to 4096 thinking it might be a stack problem. This didn't fix the problem. I looked at the heap allocation as rand calls malloc. My heap in FreeRTOS is set to 100000 and the system heap set in the linker script is 0x1000 (4k) which seems OK.
The rand function is not guaranteed thread safe so i disabled interrupts before ran is called, but it still failed at the
_exit function.
I removed the call to rand and made the number a constant 0xCOAD1234. Viz.
/**
* Initialize this module.
*/
#pragma GCC push_options
#pragma GCC optimize ("O0")
void udp_init(void)
{
#ifdef LWIP_RAND
taskDISABLE_INTERRUPTS();
// uint32_t randNo = LWIP_RAND(); /* rjg debug */
// udp_port = UDP_ENSURE_LOCAL_PORT_RANGE(59876);
udp_port = 59876;
taskENABLE_INTERRUPTS();
#endif /* LWIP_RAND */
}
#pragma GCC pop_options
This fixed the call to udp_init, but then the program crashed on the following call to tcp_init on the same macro:
void
tcp_init(void)
{
#ifdef LWIP_RAND
tcp_port = TCP_ENSURE_LOCAL_PORT_RANGE(LWIP_RAND());
#endif /* LWIP_RAND */
}
I replaced the call to rand with a fixed value:
void
tcp_init(void)
{
#ifdef LWIP_RAND
// tcp_port = TCP_ENSURE_LOCAL_PORT_RANGE(LWIP_RAND());
tcp_port = 59123;
#endif /* LWIP_RAND */
}
This allowed the tcp_init function to complete without crashing, but sadly something else went wrong in the DHCP module in the dhcp_discover function. And yes, you guessed it, the lead in the saddlebags was our old friend rand(), line 1913 of the dhcp,c module! viz:
/* DHCP_REQUEST should reuse 'xid' from DHCPOFFER */
if ((message_type != DHCP_REQUEST) || (dhcp->state == DHCP_STATE_REBOOTING)) {
/* reuse transaction identifier in retransmissions */
if (dhcp->tries == 0) {
#if DHCP_CREATE_RAND_XID && defined(LWIP_RAND)
xid = LWIP_RAND(); /* <== ****************** This one **********/
#else /* DHCP_CREATE_RAND_XID && defined(LWIP_RAND) */
xid++;
#endif /* DHCP_CREATE_RAND_XID && defined(LWIP_RAND) */
}
dhcp->xid = xid;
}
LWIP_DEBUGF(DHCP_DEBUG | LWIP_DBG_TRACE,
("transaction id xid(%"X32_F")\n", xid));
I did a search for LWIP_RAND and found it is sprinkelrd liberally around the LWIP code:
That's it for now it is lunch time.
I will make my own rand code and tackle the problem on a full stomach. Fixing this is not for the mal-nourished!
Hello @Garnett.Robert ,
can you share your IOC file generating this code after some examination it seems like you are running from address space 90000000 meaning you are executing from external memory.
are you using an external clock source other then systick as you are using FreeRTOS ?
are you configuring the Ethernet in MII mode with the correct pins assigned to the board.
a don't see why you should be stuck in a call from the standard library this is most probably a miss configuration, or we are missing something to get the full picture.
if you are using external memory, it is to note the following mentioned in UM2488
Regards
