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.

CC3130: Device locks-up and causes system rest at random periods

Part Number: CC3130
Other Parts Discussed in Thread: CC2650, CC2640, CC3120

We have a product where we have 3 TI devices, a MSP432 as the main controller a CC2650 for Bluetooth and a CC3130 for WiFi. The MSP communicates with the two other devices using a 'Simplelink' layer and all works well. We have recently noticed that some of the products exhibit a reset issue where they work for various periods e.g. 45s, 75s, 190s and then reset. It seems to be that the communication with the CC3130 is getting stuck in that there is no response back to the MSP and the watchdog then causes the reset. 

Is this a known issue and is there a resolution for it, if not has this been seen before and is there a solution that I can implement.  

  • Hi,

    This is definitely not a known issue and should not occur.

    Do you get any asynchronous events to indicate errors? For example, SL_DEVICE_EVENT_FATAL_DEVICE_ABORT or any of the SL_DEVICE_EVENT_FATAL_xxx?

    We can also try to fetch some NWO logs to understand more but let's start with this one.

    What do you transfer over between MSP and CC3130? what happens if you don't transfer anything, would it still get stuck?

    Shlomi

  • Thanks for the reply. I will do some debugging tomorrow and try and get a better idea of where exactly the issue is and if there are any errors returned. 

  • thanks, please share details when you get it.

  • I have undertaken some detailed debugging into the issue and it is not as I reported. We assumed it was as stated as we have seen this before and our resolution, which seems to work, was to re-programme the CC3120 device with its firmware. We tried that this time but it did not work. Further detailed debugging has found that the issue is with the UART_control() with a CC2640, used in-place of a CC2650. 

    Although this doesn't really solve the issue and we may need to re-visit it, if it occurs more frequently. I will mark this as resolved and raise a new question regarding the UART control of MSP432 with CC2640