2025-11-26 8:07 AM
Hello!
I am trying to get an MQTT project to work, but having some issues. At some points randomly the program stops and does not respond to the remote server anymore. In hopes of figuring it out I tried to enable stack checking from ThreadX settings from CubeMX, and generated the code. BUT, whenever the stack checking was disabled, DNS was able to retrieve the IP address always. Now, it fails every time.
The function "nx_dns_host_by_name_get" is called from the begging of SNTP thread. After calling the mentioned function, the return status is NX_DNS_QUERY_FAILED (0xA3). I have the DNS set up as to retry 3 times with a timeout of 10 seconds.
Checking from WireShark I can see that the device did send out the query to get the IP address, and the router answered, but for some reason the packet was not received/saved on the device side. After that I get 3 different ARP packets from the router, which is trying to identify my device, but no responses. Finally, 2 more attempts are made by the device to query the IP address, which do not get any responses (makes sense, when the device does not respond to the router for identification).
So, I am a bit confused and out of ideas as to what might be the cause to this problem. I mean, enabling stack checking is doing something, but I believe that there is a deeper issue/problem present in my program.
Solved! Go to Solution.
2025-12-02 5:16 AM
I managed to fix the issue by setting NX_IP_FAST_TIMER_RATE value to 10 milliseconds. Before that I had set it up last month at some point to 100 milliseconds for testing my application.
At first I thought that there was something to do with the Ethernet DMA, because I saw that it was reacting quite slowly. Only when putting a breakpoint and stopping just before the receive function I could retrieve the DNS packet. But it turned out that the cause for this problem was the slow thread that was dealing with the Ethernet packets.
But thanks, @TDK for the suggestions!
2025-11-26 1:35 PM
Perhaps debug the application and see if the stack checking succeeds. If you are overflowing the stack, the behavior is undefined. Note that things "working" do not mean the code doesn't have bugs or that the stack isn't overflowing.
See why things "randomly stop" by examining the state when this happens. Hit pause, see where execution is at, see why things are not progressing, etc. This is standard debugging.
If the code no longer works after enabling stack checking, perhaps the application threads are overflowing their stack.
2025-11-27 7:55 AM
So far what I found is that something in the _nx_dns_response_receive function in the nxd_dns.c file is happening, and not sure yet what exactly. When I put a breakpoint on this line
/* Initialize the value. */
start_time = tx_time_get();, and before letting it run again, when I wait for a second, then the nx_udp_socket_receive function is able to retrieve the DNS response packet. But, when i do not let it wait for a second, then the system is unable to get the DNS response packet. I added a 1 (also tried 2 and 3) second delay before calling nx_udp_socket_receive(), but that did not help out.
Also, using WireShark, I saw that when the system stopped at the breakpoint on the mentioned line, then no DNS query is sent out, only after when tx_time_get() function has ran. Not sure if this somehow plays a roll in this or not.
As far as I have seen, memory is fine, there is no overflow happening. I also tried adding more memory for the stacks, but it not have any effect.
2025-12-02 5:16 AM
I managed to fix the issue by setting NX_IP_FAST_TIMER_RATE value to 10 milliseconds. Before that I had set it up last month at some point to 100 milliseconds for testing my application.
At first I thought that there was something to do with the Ethernet DMA, because I saw that it was reacting quite slowly. Only when putting a breakpoint and stopping just before the receive function I could retrieve the DNS packet. But it turned out that the cause for this problem was the slow thread that was dealing with the Ethernet packets.
But thanks, @TDK for the suggestions!