2025-10-13 5:30 AM - edited 2025-10-13 8:03 AM
Hello!
I am using a custom board with STM32H563VIT6. I want to create an MQTT project which will send data to a local laptop via an Ethernet cable. I am using STM32H573I-DK\Applications\NetXDuo\Nx_MQTT_Client as the example project to do so, but I am facing a problem.
The problem is that when the nx_app_thread_entry function is called it will get stuck when this line is called
if(tx_semaphore_get(&DHCPSemaphore, TX_WAIT_FOREVER) != TX_SUCCESS)Then this leads to "__tx_ts_wait" in the nx_thread_schedule.S forever.
This is my call stack up to __tx_ts_wait:
__tx_ts_wait@0x08000336 (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\ports\cortex_m33\gnu\src\tx_thread_schedule.S:279)
<signal handler called>@0xffffffbc (Unknown Source:0)
_tx_ipsr_get@0x08009bdc (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\ports\cortex_m33\gnu\inc\tx_port.h:511)
_tx_thread_system_return_inline@0x08009bdc (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\ports\cortex_m33\gnu\inc\tx_port.h:615)
_tx_thread_system_suspend@0x08009bdc (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\common\src\tx_thread_system_suspend.c:380)
_tx_thread_sleep@0x080098fe (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\common\src\tx_thread_sleep.c:189)
App_Link_Thread_Entry@0x08035768 (...\STM32H563VIT6_Ethernet\NetXDuo\App\app_netxduo.c:841)
_tx_thread_shell_entry@0x08009764 (...\STM32H563VIT6_Ethernet\Middlewares\ST\threadx\common\src\tx_thread_shell_entry.c:114)
<signal handler called>@0xffffffff (Unknown Source:0)What could be the issue? Any help or ideas to solve it would be greatly appreciated!
Edit 1: If I understand it correctly, at the start a DHCP server is created and IP address change callback is registered (when the IP change is done, then the system can "move on" to MQTT part). For now the system is trying configure the IP address for the device client (which is the board with STM), but no IP address gets to be set for the device, so then the system will wait forever, and in the meantime nothing else is also working (MQTT service). If I understood this correctly, then does it mean that the software is not the issue, but perhaps the problem is in the connection between the MQTT client (STM device) and my laptop?
Adding files, including ioc, that might be of help.
Solved! Go to Solution.
2025-10-14 9:32 AM
Hello @Sander_UP,
I ported the project to STM32H563ZIT with your same configuration and was able to acquire the DHCP semaphore successfully and get an IP assigned. Are you sure you have a DHCP server running on your computer when you ran this application? Otherwise, it will get stuck at that step.
In your 2nd edit, you mentioned trying a simple UDP echo client on a Nucleo-STM32H563ZIT6 dev board, but the device was unable to send UDP packets. In that example, you need to specify the server IP address (your computer's IP) and port to send your ECHOs, then rebuild the project. If that doesn’t help, install a packet monitoring tool like Wireshark to monitor your Ethernet interface and see if the device is sending packets but not receiving replies, or not sending at all.
In your STM32CubeMX configuration, I saw you set PA4 as ETH_RST. Are you using that signal in your application to reset the Ethernet peripheral? What is it connected to?
Best regards,
2025-10-13 7:55 AM
Hello @Sander_UP, and welcome to ST community!
Could you try stepping through the tx_semaphore_get function? This will help us determine why the application fails to acquire the semaphore, as each check in that function is well documented.
Best regards,
2025-10-13 8:32 AM - edited 2025-10-14 8:05 AM
Hello, @STackPointer64
I stepped through the function, and I am getting stuck at this point:
/* Restore interrupts. */
TX_RESTORE
/* Determine if preemption should take place. This is only possible if the current thread pointer is not the same as the execute thread pointer AND the system state and preempt disable flags are clear. */
TX_THREAD_SYSTEM_RETURN_CHECK(combined_flags)
if (combined_flags == ((ULONG) 0))
{
#ifdef TX_THREAD_ENABLE_PERFORMANCE_INFO
/* No, there is another thread ready to run and will be scheduled upon return. */
_tx_thread_performance_non_idle_return_count++;
#endif
/* Preemption is needed - return to the system! */
_tx_thread_system_return();
}
/* Return to caller. */
return;The code falls inside the if clause and the runs the _tx_thread_system_return function, returns and then comes back here again. @STackPointer64 does this give You any more clues as what is happening? I can do more debugging and testing tomorrow!
Edit 1:
I did some more digging, and found another weird thing in the app_netxduo.c file
static VOID App_Link_Thread_Entry(ULONG thread_input)
{
ULONG actual_status;
UINT linkdown = 0, status;
while(1)
{
/* Send request to check if the Ethernet cable is connected. */
status = nx_ip_interface_status_check(&NetXDuoEthIpInstance, 0, NX_IP_LINK_ENABLED,
&actual_status, 10);
if(status == NX_SUCCESS)
{
if(linkdown == 1)
{
...Every time the nx_ip_interface_status_check function is called, NX_SUCCESS is returned, does not matter if the Ethernet cable is connected or not. Also, it seems that the device (our custom board that has the STM chip) is not capable of checking the link status. And as I understood from that code, in order get further, the system has to first detect that the link is down
if(0 == linkdown)
{
linkdown = 1;
/* The network cable is not connected. */
// printf("The network cable is not connected.\n");
nx_ip_driver_direct_command(&NetXDuoEthIpInstance, NX_LINK_DISABLE,
&actual_status);
}then the linkdown flag will be set to 1, and then the PHY link is established. After that the DHCP thread is closed, and the program can eventually start to send MQTT packets. But since the Ethernet cable cannot be checked if it is actually connected or not, the program remains in an infinite loop.
I tested my laptop with another laptop, and the problem is not in the network sharing or in the Ethernet port itself.
At this point, I think that I am missing something (wrong settings configured from CubeMX), but also not 100% sure that this is causing the issues, could be something else that I have not thought about yet.
Edit 2:
I tried a simple UDP Echo client with the STM32H564ZIT6 Nucleo Devboard - did not change anything, code generated from the example project Nx_UDP_Echo_Client. The problem I described in Edit 1 is not present here, but the device is unable to send any UDP packets. I get this from the output:
Nx_UDP_Echo_Client application started..
The network cable is not connected.
The network cable is connected.
STM32 IpAddress: 192.168.137.64
-------------------------------------
FAIL : 0 / 100 packets sent
-------------------------------------I used different Ethernet cables, switched off Windows firewall and tested on a different laptop (Windows 11). Also, installed an application for Windows that creates DHCP server - the program worked up, but the device was unable to send packets (from the board to the laptop). Additionally, allowed internet connection sharing from the control panel - still no help.
@STackPointer64 Are there some specific settings needed to be changed on Windows based computers or some different settings to be configured from CubeMX?
2025-10-14 9:32 AM
Hello @Sander_UP,
I ported the project to STM32H563ZIT with your same configuration and was able to acquire the DHCP semaphore successfully and get an IP assigned. Are you sure you have a DHCP server running on your computer when you ran this application? Otherwise, it will get stuck at that step.
In your 2nd edit, you mentioned trying a simple UDP echo client on a Nucleo-STM32H563ZIT6 dev board, but the device was unable to send UDP packets. In that example, you need to specify the server IP address (your computer's IP) and port to send your ECHOs, then rebuild the project. If that doesn’t help, install a packet monitoring tool like Wireshark to monitor your Ethernet interface and see if the device is sending packets but not receiving replies, or not sending at all.
In your STM32CubeMX configuration, I saw you set PA4 as ETH_RST. Are you using that signal in your application to reset the Ethernet peripheral? What is it connected to?
Best regards,
2025-10-15 8:45 AM
Hello, @STackPointer64. Thank You for the response!
1. Yes, the DHCP server is running, and now the DHCP thread is running successfully. Just had to configure addresses to be correct in order for it to work.
2. You are right, the IP address that was written before was incorrect, after fixing it the example project is now working correctly. Also, had to use a different port number other than 6000, because the echotool was giving an error, so just had to use a port number that was not in use.
3. The pin PA4 is used to do a reset to the LAN8742 chip on the board. Without setting it to HIGH, the ETH_Init function will not be successful.
Coming back to the MQTT project - today I am facing a new issue. The problem now is with the SNTP thread after calling nx_dns_host_by_name_get function. The error status I receive is following: NX_DNS_QUERY_FAILED error "DNS query failed; no DNS server sent an 'answer'". Also, from my network settings I see that the device is unable to get Internet connection. Is it due to that?
Is the MQTT example even meant to be used with a laptop or a computer (Ethernet cable running from the device to a computer), or could there just be a problem with my laptop (or the network driver)?
I have not yet gotten time to test the setup with a router, but will do so tomorrow.
2025-10-15 8:56 AM
Hello @Sander_UP,
I’m glad that your issue is resolved. Since you are now facing a new problem, I suggest opening a new community thread for it so we avoid confusing future readers. I would be happy to assist you there.
Best regards,