2024-06-19 04:01 AM
Hello,
i have running an web applikation with netXduo on an STM32H735 and i try to open a TCP connection.
Driver, initialization, communication and stuff is working, but for testing purpose i tried to let the netXduo API-calls to run into timout by setting the waitOpt to a very low time.
But nothing happened, e.g. with nx_tcp_socket_receive with a timeout of only a few ticks, the stack waits till the next packet is received. The function doesn't return on timeout.
I have also tried nxd_tcp_client_socket_connect, also this function does not timeout. It stucks infinitely if it can't establish the connection, although timeout is configured.
Can anyone give me a hint, why these functions (and probably others too) will not return by timeout?
best regards
Solved! Go to Solution.
2024-06-27 01:03 AM
Hello,
luckily i found the bug on my own.
Different to all of the ST examples, i use the Stack with wrappers in a C++ environment, most of the netX, threadX, ... handlers are members of classes.
In this case, the content of these handlers (e.g. NX_PACKET_POOL, NX_IP, NX_TCP_SOCKET, ...) aren't initialized to zero by startupcode / by default. But the libs expect that these memories are cleared.
Instantiation like:
NX_TCP_SOCKET m_tcpSocket = {0};
solved the issue.
That means, for all users, who use dynamic memories allocated during runtime: clear the contents of the structures prior initializing/using them with the appropriate nx/tx/... create-function.
@st: to avoid such, hard to find problems and protect other costumers, i would recommend, that you update all of your demo-projects and add "= {0}" whenever needed. Not in all environments these zero-initialization is done automatically by the init-code.
best regards
2024-06-20 01:52 PM
This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.
2024-06-27 01:03 AM
Hello,
luckily i found the bug on my own.
Different to all of the ST examples, i use the Stack with wrappers in a C++ environment, most of the netX, threadX, ... handlers are members of classes.
In this case, the content of these handlers (e.g. NX_PACKET_POOL, NX_IP, NX_TCP_SOCKET, ...) aren't initialized to zero by startupcode / by default. But the libs expect that these memories are cleared.
Instantiation like:
NX_TCP_SOCKET m_tcpSocket = {0};
solved the issue.
That means, for all users, who use dynamic memories allocated during runtime: clear the contents of the structures prior initializing/using them with the appropriate nx/tx/... create-function.
@st: to avoid such, hard to find problems and protect other costumers, i would recommend, that you update all of your demo-projects and add "= {0}" whenever needed. Not in all environments these zero-initialization is done automatically by the init-code.
best regards