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.
Part Number: CC3120MOD
In line with my other posts, we've been tracking down instability in the CC3120MOD devices and the SL driver.
Our CC3120MOD devices have sp_18.104.22.168_22.214.171.124_126.96.36.199 on them.
On one of our designs we have a logic analyser setup to monitor the comms and capture any fatal driver events.
The two attached logic capture files show:
TP_4 : A pulse when SimpleLinkFatalErrorEventHandler() is called.
TP_6: A pulse to indicate when driver.c lines ~2120 when the driver is trying to "Read 8 bytes (protocol aligned) - expected to be the sync pattern"
SPI: As normal
Other signals : Not Used
Note: The capture is triggered on TP4 and therefore all data is captured prior to this, not after this event.
By looking at the data, you can quite clearly see that the CC3120MOD device DOES NOT return the sync word.
I've been pulling my hair out over the SL driver, but maybe the hardware contributes to it.? Its very clear the CC3120MODA returns data, but no SYNC data.!
Can someone from TI please look over the files and advise.
I'm pretty sure you're not seeing sync word data because you're getting a sync loss event in the fatal event handler. Are you doing some kind of testing to purposefully generate this event?
We are glad that we were able to resolve this issue, and will now proceed to close this thread.
If you have further questions related to this thread, you may click "Ask a related question" below. The newly created question will be automatically linked to this question.
In reply to Jesu:
Let me refer to the attached logic captures, specifically SyncLoss -03.logicdata.
At about time -55.76ms a read is performed and the sync word is found. This is the start of the TP6 pulse which occurs when the driver starts the read operation.
At time -50.67ms another read operation takes place, this time the sync word is never returned from the CC3120MOD. This event lasts for exactly the timeout duration of 50ms and at time 0.0ms TP4 indicates the SL driver as triggered the fatal event handler.
As for our testing we have device on our network broadcasting UDP packets (to the broadcast address) and over the top of that we are using our MSP432P4111 + CC3120MOD to send a UDP unicast packet every 500ms, as well as have an Amazon AWS task running.
We find that this sync loss event is most likely to happen with the high UDP broadcast traffic.
In reply to stomp:
I have a fix for this problem, and the other problems I have been seeing as per: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/856202
Here is my solution:
1. Make sure all of the tasks that use the SL driver have a priority BELOW that of the SL driver.
2. Patch _SlDrvRemoveFromList() (line 2549 in driver.c) such that array bounds are correctly checked. Failure of this function to perform correctly occurs when we call sl_Stop() at random points in our application lifecyle, which could be anything from changing wlan modes, to user request power down / sleep via a pushbutton.
3. Upon reception of a fatal event, the SL driver will memory leak and fail. The reason being is the fatal event just calls function returns at random points in the driver. This in-turn means that objects are not deleted, and a subsequent call to sl_Start just zero's out the memory that was created via Malloc. We have removed the posix threads calls and written our own FreeRTOS ones explicitly null objects after they have been deleted and return success even if a null object is acted upon. This way the SL driver can exit uncleanly and not disturb the OS.
4. Forgot to mention _SlInternalSpawn() in spawn.c needs to be patched such that on FreeRTOS if you are calling using the FROM_CMD_CTX flag, that you do not call ISR context functions. I split the if statement on line 120 of spawn.c such that any SL_SPAWN_FLAG_FROM_CMD_CTX flags will signal the sync object from a non ISR FreeRTOS semaphore function.
After these measures have been implemented we have put 10e4 UDP packets through our systems without fault.
Hopefully TI can look a bit more closely at the above recommendations (the first and thrid may only be specific to FreeRTOS) and maybe even provide an example project to trigger a FatalEvent and show us how to handle it correctly.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.