Because of the Thanksgiving holiday in the U.S., TI E2E design support forum responses may be delayed the week of Nov. 21. Thank you for your patience.

CC3100: Unresponsive Simplelink driver

Part Number: CC3100


We've noticed that our devices sometimes enter a state where the simplelink driver becomes unresponsive.

  • Issue starts to happen after a successful publish attempt via sl_ExtLib_MqttClientSend(). Any subsequent attempts fail with error code -5 (MQP_ERR_PKT_AVL).
    • The device gets stuck in this state until a reset occurs


  • Reproduction is sporadic. It's rare. Sometimes it takes a few tries, other times 100s
  • Some low priority threads are being starved.
  • Powering off the AP does not trigger the disconnect event. I.e., the WifiMgr__SimpleLinkWlanEventHandler() is not called. In the AP the device is not shown to be connected.
  • MQTT disconnect initiated by broker (seen on our BE) due to lack of pings.
  • The SL driver never invokes any of the registered callbacks (e.g., sl_ExtLib_MqttEvent and sl_ExtLib_MqttDisconn) when in this state. I.e., even though we see that the broker has disconnected, the SL driver never notifies the device that that is the case.
    • We never see the SL_MQTT_CL_EVT_PUBACK or SL_MQTT_CL_EVT_PINGRSP events. Again, because the sl_ExtLib_MqttEvent callback never gets called when in this state.

Debugging seems to present that there's something wrong with the SPI comms. See the following call stack:

    0. HAL_SPI_TransmitReceive

    1. HAL_SPI_Receive

Application Level Functions

    2. CC3100Spi__SpiRead

SL Driver Functions

    3. _SlDrvRxHdrRead

    4. _SlDrvMsgRead

    5. _SlDrvMsgReadSpawnCtx

    6. _SlInternalSpawnTaskEntry

Is it possible that there is an event or mutex/semaphore that the Simplelink driver is stuck on? 

Version Info:

Chip FW:
Chip PHY:

Thank you