cancel
Showing results for 
Search instead for 
Did you mean: 

netXduo Ethernet Stack - nx_tcp_socket_receive does not timeout

AZorn.1
Associate III

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

 

1 ACCEPTED SOLUTION

Accepted Solutions
AZorn.1
Associate III

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

View solution in original post

2 REPLIES 2
Douglas MILLER
ST Employee

This post has been escalated to the ST Online Support Team for additional assistance. We'll contact you directly.

AZorn.1
Associate III

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