CC3100: Unresponsive Simplelink driver

Seems like the NWP gets stuck somehow (and less likely a problem with the SPI porting). I don't think it is a known issue.

Can you provide NWP logs? (/cfs-file/__key/communityserver-discussions-components-files/968/CC3100-_2600_-CC3200-Capture-NWP-Logs-_2D00_-Texas-Instruments-Wiki.pdf)

Are you printing a-sync events received in SimpleLinkGeneralEventHandler? (if so, did you see any such event happens before the issue appears)?

Have you tried resetting the NWP with sl_Stop/sl_Start (you will need to reconnect to the MQTT broker following this and after the reconnection to the AP)?

We are printing out async events but we do not see any of those events getting triggered at all (when in this state).

I have not tried an sl_stop()/start() cycle. I will do that and capture NWP logs when I'm able to reproduce.

Thank you

Here are the NWP logs:

NWP_Capture_1.txt

The issue starts about ~4 minutes in. NWP output stops completely when in this state.

Calling sl_stop() -> start() when this issue occurs seems to freeze everything.

I also noticed this old post:https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/528514/issues-with-cc3100-on-stm32f207-using-freertos?tisearch=e2e-sitesearch&keymatch=sl_WlanEvtHdlr#. What is the recommended stack size for the WiFi and spawn threads? Currently our stack sizes are set to 2048 and 1024 respectively. Is that too low?

seems that you host code is still running so i don't think the stack is the issue. Can you use the debugger to suspend the execution and check where the code is.

What does it means that NWP reset freezes everything? Do the sl_Stop/Start return? (with errors?) You will need to reconnect to the MQTT server once you get the indication of IP Acquire. Since the issue relates to missing buffers, you better close mqtt (call sl_ExtLib_MqttClientCtxDelete and sl_ExtLib_MqttClientExit) and start it again (i.e. basically running the mqttClient thread again - if you are based on our mqttClient example).

I saw one issue in the NWP but it happens immediately upon connection and the NWP recovers from it so it doesn't seem related to the issue here. 

I shared the call stack taken when I stopped the debugger. It seems to always stop trying to read something from the CC3100 via _SlDrvRxHdrRead see call stack 3-6 above. 

Whenever I call sl_Stop -> sl_Start manually the device seems to get stuck. I.e., cannot be communicated with. I will try to dig into this specifically a bit more and will update here with that I find.

So may be a problem with the host driver.

Are you on the latest 1.5 SDK?

I am on the latest 1.5 SDK, yes.

Since I can't communicate with the device via FW is there a way to check if it's still active? (e.g., via probing, sniffing, etc). 

Also, how does the Simplelink driver know when the Broker has disconnected? Does it keep track of the Keep Alive timeout internally, with successful pings?

the MQTT is using keepalive to identify disconnection from the broker.

There are mutexes in the driver. how confident are you with your CC3100 platform porting? 

This can definitely be a porting issue.

Did you say that the NWP Log stopped when the issue happened? 

Yes, as soon as our device gets into this state, the NWP logs abruptly stop.

Can you provide a new instance of the NWP log? I want to check if the issue happens at the same place.

The stop of the NWP log may indicate that the NWP crashed (without printing any assert message), but on the other end, this kind of issue should have been recovered by the sl_Stop/sl_Start.

So i set up a custom application that publishes a message using sl_ExtLib_MqttClientSend every 2 seconds. After 24 hrs, the application did not reproduce the issue. I'm believe this is some sort of race condition in our code. I will investigate further and re-open a ticket if needed. Thank you 

ok. thanks for the update