Skip to main content
Graduate
June 19, 2024
Solved

netXduo Ethernet Stack - nx_tcp_socket_receive does not timeout

  • June 19, 2024
  • 2 replies
  • 1779 views

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

 

    This topic has been closed for replies.
    Best answer by AZorn.1

    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

    2 replies

    ST Employee
    June 20, 2024

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

    AZorn.1AuthorAnswer
    Graduate
    June 27, 2024

    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