This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2530: TIMEOUT waiting for confirmation - NWKMGR thread stops - NWKMGR continues running - ZIGBEE-LINUX-SENSOR-TO-CLOUD_1.0.1

Part Number: CC2530

Sometime the application will indicate "TIMEOUT waiting for confirmation" and do so consistently.

It turns out that this is because one of the NWKMGR's threads stopped - normally there are 4 threads.  They were assigned names in my updated code, 

So it is the first thread of the two that are created here in "api_client.c":

  /****************************************************************************
   * Create thread which can read new messages from the serial interface server
   ****************************************************************************/

  if ( pthread_create( &pInstance->SISRThreadId, &attr, SISreadThreadFunc,
      pInstance ) )
  {
    // thread creation failed
    uiPrintf( "Failed to create RTIS LNX IPC Client read thread\n" );
    close( pInstance->sAPIconnected );
    freeaddrinfo( pInstance->resAddr );
    delSyncRes( pInstance );
    free( pInstance );
    return NULL;
  }
  pthread_setname_np(pInstance->SISRThreadId,"RTISLNX_IPC_RD");


  /******************************************************************************
   * Create thread which can handle new messages from the serial interface server
   ******************************************************************************/

  if ( pthread_create( &pInstance->SISHThreadId, &attr, SIShandleThreadFunc,
      pInstance ) )
  {
    // thread creation failed
    uiPrintf( "Failed to create RTIS LNX IPC Client handle thread\n" );
    close( pInstance->sAPIconnected );
    pthread_join( pInstance->SISRThreadId, NULL );
    freeaddrinfo( pInstance->resAddr );
    delSyncRes( pInstance );
    free( pInstance );
    return NULL;
  }
  pthread_setname_np(pInstance->SISHThreadId,"RTISLNX_IPC_HND");

According to the application output, the end of the thread left no indication of the reason:

[2020-11-25 16:42:00.149355] [NWK_MGR/LSTN] INFO   : ...sent 12 bytes to Client
[2020-11-25 16:42:00.149378] [NWK_MGR/LSTN] INFO   : !Done
[2020-11-25 16:42:00.211289] [NWK_MGR/READ] INFO   : Received 9 bytes, subSys 0x51, cmdId 0x80
[2020-11-25 16:42:00.211304] [NWK_MGR/READ] INFO   : RPC_CMD_AREQ cmdId: 0x80
[2020-11-25 16:42:00.211307] [NWK_MGR/READ] INFO   : [DBG] Allocated 	@ 0xF7C00568 (received  26 messages)...
[2020-11-25 16:42:00.211310] [NWK_MGR/READ] INFO   : Filling new message (@ 0xF7C00568)...
[2020-11-25 16:42:00.211504] [NWK_MGR/LSTN] INFO   : Receive message...
[2020-11-25 16:42:00.211516] [NWK_MGR/LSTN] MISC1  : SRVR_GET_IEEE_ADDRESS_REQ: shortAddr: DB51
[2020-11-25 16:49:57.012509] [NWK_MGR/READ] INFO   : Peer closed connection

As the Network Manager is still running (which can be seen in the UI of the sample applicaiton, everything seems OK while it isn't.

So this calls for some kind of monitoring of the threads, and also identifying the reason why the thread stopped and fix it.