Radio becomes unresponsive

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Félix_T
Level 5
Level 5
10 sign-ins First comment on blog 50 replies posted

Using WICED 6.4.0.61, STM32L4+ connected to a 43012C0

I am running into an issue when sending data to a connected socket using the NETX API. After some time, anywhere from 2-20 minutes, my tcp sends return NX_NOT_CONNECTED. I've watched the connection in wireshark, and there is no FIN or RST being sent by either side of the connection. All traffic from the device stops, the server sends one keep alive, and finally the server RST the connection. When this happens, other wiced API calls, like getting the RSSI, hang indefinitely. I have tried closing the socket, and attempting to reconnect, but all attempts at connecting eventually return NX_NOT_CONNECTED. Even taking down the interface and attempting to rescan and connect to the AP fails on the scan call.

What I have noticed is that the WWD thread appears to be waiting on the SDIO semaphore, and never seems to unblock. Does anyone know what is happening, or if there is a work around for this which does not require restarting the chip from scratch?

Below is the stack trace for the WWD thread.

 

#0 __restore_interrupts (primask_value=2147483648)
threadx/5_8/tx_port.h:488
#1 _tx_thread_system_return_inline ()
threadx/5_8/tx_port.h:488
#2 _tx_thread_system_ni_suspend (thread_ptr=<optimized out>, thread_ptr@entry=0x200019d4
<wwd_thread>, wait_option=<optimized out>)
threadx/5_8/tx_thread_system_suspend.c:1278
#3 _tx_semaphore_get (semaphore_ptr=<optimized out>, wait_option=<optimized out>)
threadx/5_8/tx_semaphore_get.c:239
#4 _txe_semaphore_get (semaphore_ptr=semaphore_ptr@entry=0x200025b4 <sdmmc1_sem>,
wait_option=wait_option@entry=4294967295)
threadx/5_8/txe_semaphore_get.c:179
#5 host_platform_sdio_cmd (command=command@entry=SDIO_CMD_53, argument=argument@entry=2751496256,
response_expected=<optimized out>, response_expected@entry=(unknown: 164)
host_platform_wiced.c:314
#6 host_platform_sdio_transfer (command=SDIO_CMD_53, response=0x0, response_expected=(unknown: 164)
host_platform_wiced.c:531
#7 host_platform_sdio_transfer (direction=<optimized out>, command=<optimized out>,
mode=<optimized out>, block_size=<optimized out>, argument=<optimized out>, data=<optimized out>,
data_size=<optimized out>, response_expected=<optimized out>, response=<optimized out>)
host_platform_wiced.c:463
#8 wwd_bus_sdio_cmd53 (response_expected=RESPONSE_NEEDED, response=0x0, data=0x200208f0
<g_tx_mem+64> "a", data_size=<optimized out>, address=0, mode=<optimized out>, function=<optimized
out>, direction=<optimized out>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/wwd_bus_protocol.c:708
#9 wwd_bus_sdio_transfer (direction=<optimized out>, function=<optimized out>,
address=address@entry=0, data_size=<optimized out>, data=0x200208f0 <g_tx_mem+64> "a",
response_expected=RESPONSE_NEEDED)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:663
#10 wwd_bus_transfer_bytes (direction=direction@entry=BUS_WRITE,
function=function@entry=WLAN_FUNCTION, address=address@entry=0, size=size@entry=97,
data=0x200208f0 <g_tx_mem+64>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:644
#11 wwd_bus_send_buffer (buffer=0x200208b0 <g_tx_mem>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/bus_protocols/SDIO/
wwd_bus_protocol.c:220
#12 wwd_thread_send_one_packet ()
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/wwd_thread.c:184
#13 wwd_thread_func (thread_input=<optimized out>)
wiced-sdk/43xxx_Wi-Fi/WICED/WWD/internal/wwd_thread.c:357

 

0 Likes
1 Solution
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

   I just want us on the same page by using same code to verify the function.  Now I am running a whole afternoon and never find CMD53 error by using the default iperf example with 43012 evb.   So I am asking the same test:

1. if your board can run well always,  Now the reason should be due to the code layer , maybe application or stack flow. 

2.  if your board can't run well,   same cmd53 stall happens,  I think we need to check the stability of the SDIO interface of  your board. 

 And did you get circuit reviewed from module maker ? 

View solution in original post

0 Likes
8 Replies
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

   I have a 43012c0 evb to run a  iperf throughput test , it doesn't fail for a long-run more than 10 minutes, 

I want to what is the difference from your environment :

1.   are you using a third-part module of 43012 to do the test ?

     if you can tell the difference of the board , it will be better . 

2.  what is changed in rtos os and net protocol ?  I am using the default compile and download command:

    test.iperf_app-CYW943012EVB_04 ,

   so I am using the Threadx+Netx-duo for the test.

3.   test app change,   I think you can use the default iperf embedded for a TCP or UDP long-run test  in the first place. 

0 Likes

The module we are using for the 43012 is the Azurewave AH306.

The RTOS we are using is threadx and the network stack is NETX (not NETXDuo).

We are using custom software to send the tcp packets, but it essentially reduces down to the following:

assert(nx_tcp_socket_create(&ip_handle, &g_client_socket,
        "Socket", NX_IP_NORMAL, NX_FRAGMENT_OKAY, 0x80, 200, NX_NULL,
         NX_NULL) == NX_SUCCESS);

/* Bind to port */
assert(nx_tcp_client_socket_bind(&g_client_socket, port, NX_WAIT_FOREVER) == NX_SUCCESS);

 /* Connect to sever */
err = nx_tcp_client_socket_connect(&g_client_socket, ip, port, NX_WAIT_FOREVER);

/* Configure TCP ack timeouts */
nx_tcp_socket_transmit_configure(&g_client_socket, 50, 100, 2, 0);

 while (0 != ret)
{
   packet_buf = get_next_data_to_tx();

   queue_bus_set_wait_option(&dev_qbus1, TX_NO_WAIT);

   assert(nx_packet_allocate(tx_packet_pools &packet, NX_TCP_PACKET,
                             NX_WAIT_FOREVER) == NX_SUCCESS);

   /* Append request to packet */
   assert(nx_packet_data_append(packet, packet_buf, ret,
          tx_packet_pool, NX_WAIT_FOREVER) == NX_SUCCESS);

   /* Send request */
   retry = 0;
   do
   {
      err = nx_tcp_socket_send(&g_client_socket, packet, 12);
      if (NX_SUCCESS != err)
      {
         retry++;
      }
   }
   while(NX_WINDOW_OVERFLOW == err && retry < 3);

   if (err)
   {
      if (NX_NOT_CONNECTED == err)
      {
         //At this point, the module becomes unusable without a reset
         //If the error is something other than NX_NOT_CONNECTED, the module
         //will continue to work
      }
      assert(nx_packet_release(packet) == NX_SUCCESS);
   }
}

 

The server never sends data back to the device, other than the TCP ACKs, so receiving packets is not shown here.

Finally, after some further testing, if I send 1 to 2 packets every 30 seconds, the device seems to run indefinitely. If I scale it up to 10 packets per second, then after ~20 minutes the module becomes unresponsive, with WWD hanging on the SDIO request.

0 Likes
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

   We have  a socket create api in the release,  I think the WINDOW size, WICED_TCP_TX_DEPTH_QUEUE,  retries , are the critical parameters.

You can have a reference .

and we have tcp reference code which was verified by many projects.

43xxx_Wi-Fi\apps\snip\tcp_client,  so if you can use them for a verification, it will be better.

wiced_result_t wiced_tcp_create_socket( wiced_tcp_socket_t* socket, wiced_interface_t interface )
{
UINT result;

memset( socket, 0, sizeof(wiced_tcp_socket_t) );

/* Set magic number for validating wiced_tcp_socket_t object and differentiating with a native NX_TCP_SOCKET object */
socket->socket_magic_number = WICED_SOCKET_MAGIC_NUMBER;

result = nx_tcp_socket_create( &IP_HANDLE(interface), &socket->socket, (CHAR*)"", NX_IP_NORMAL, NX_FRAGMENT_OKAY, NX_IP_TIME_TO_LIVE, WICED_TCP_WINDOW_SIZE, NX_NULL, NX_NULL );
wiced_assert("Error creating socket", result == NX_SUCCESS);
nx_tcp_socket_transmit_configure(&socket->socket, WICED_TCP_TX_DEPTH_QUEUE, WICED_TCP_SEND_TIMEOUT/WICED_TCP_TX_RETRIES, WICED_TCP_TX_RETRIES, 0);

return netx_returns[result];
}

0 Likes

I don't think this will do anything different. The issue is that the 43012 stops talking on the SDIO. I changed the SDIO driver to retry the transfers 5 times if fails, and if that fails the error passes back up to wwd_thread.c where wwd_thread_send_one_packet is called. This call is wrapped in a do-while which will try to resend the packet forever as long as it fails.

The WWD code is stuck, trying to send the same packet forever, because the SDIO transfer always fails.

0 Likes
Félix_T
Level 5
Level 5
10 sign-ins First comment on blog 50 replies posted

When the device gets "stuck", it still responds to SDIO CMD52. The check to see if the backplane is up succeeds, repeatedly, but the following CMD53 (the data) always fails to complete. The CMD53 transfer doesn't report an error, it just stalls.

0 Likes
Zhengbao_Zhang
Moderator
Moderator
Moderator
250 sign-ins First comment on KBA 10 questions asked

Hello:

   I just want us on the same page by using same code to verify the function.  Now I am running a whole afternoon and never find CMD53 error by using the default iperf example with 43012 evb.   So I am asking the same test:

1. if your board can run well always,  Now the reason should be due to the code layer , maybe application or stack flow. 

2.  if your board can't run well,   same cmd53 stall happens,  I think we need to check the stability of the SDIO interface of  your board. 

 And did you get circuit reviewed from module maker ? 

0 Likes

This is an early development board so it is possible that the SDIO is unstable. The circuit was reviewed by the module maker, and it meets all of their specifications. But as this is an early dev board, traces for the SDIO may not be optimal. I will try with a newer, smaller board that has much shorter traces and post back when I get results.

Thanks.

0 Likes
Roy_Liu
Moderator
Moderator
Moderator
5 comments on KBA First comment on KBA 10 questions asked

Please start a new thread if needed.

Roy Liu
0 Likes