• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 42 subscribers
  • Views 284 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC3220SF: getting -2011 in InitSimplelink function

Abhishek Pratap Singh
Intellectual 425 points
Part Number: CC3220SF


Hi,

I am using CC3220SF WiFi SoC in our devices. We are in production stage and has already completed lots of devices till now.

Recently we are facing device reboot while performing test for modules.

Device is reboot frequently with error msg:  Error [-2011] at line [1575] in function [InitSimplelink]

In code it is getting stuck at below point.

line 1574 :  retVal = sl_WlanSetMode(pCtx->role);
line 1574 :  ASSERT_ON_ERROR(retVal);

In slneterr.h file this error is mentioned as below

/* API has been aborted, command is not allowed in device lock state */
#define SLNETERR_RET_CODE_DEV_LOCKED (-2011L)

Please help us to understand this error and possible reasons that may lead to this error.

  • 0
    TI__Genius 14651 points

    Hi Abhishek,

    In section 3.3.4 of the Network Processor Guide gives the following reasons on why a lock state would occur.

    The device can enter a lock state due to one of the following conditions:

    • The restore to factory defaults is currently in process. The device unlocks when the process is finished.

    • The device INIT failed and an inaccurate error is sent with the INIT-complete error asynchronous event. The device INIT-complete may fail due to calibration failure or integrity failure of the file-system data structure.

    • The security alerts threshold was exceeded. The SimpleLink Wi-Fi device provides a software tampering detection mechanism with a security-alert counter. This procedure detects integrity violation of the following: file-system data, secure-authentication files, or system files. When the device reaches the security alerts threshold (three by default or predefined with Image Creator), it locks.

    • A critical security alert occurs.

    Some files may have been corrupted and making the device lock.

    Kind Regards,

    Rogelio

  • 0 in reply to RogelioD
    Intellectual 425 points

    Hi

    I checked in more detail and the above error is due to SL_ERROR_CALIB_FAIL error for sl_Start(0, 0, 0) this function.

    I am facing this as soon as my device starts? what can be the reasons for this. I am still testing to find out more on this. We have done production of few batches before but this issue is occurring more frequently with current patch of devices.

  • 0 in reply to Abhishek Pratap Singh
    Intellectual 425 points

    Just for info, current SDK version is simplelink_cc32xx_sdk_3_30_01_02

  • 0 in reply to Abhishek Pratap Singh
    TI__Genius 14651 points

    Hello,

    I am looking into why this error could occur. Meanwhile I definitely would update to the newest version of the sdk.

    Kind regards,

    Rogelio

  • 0 in reply to RogelioD
    Intellectual 425 points

    Hi Rodelio,

    We have already produced lots of quantity till now with same version without any issue(5K+) so I am not sure if changing SDK will fix things here. Additionally we are at a stage where migrating to new SDK is not feasible. Lots of devices are running in field already using same SDK version.

    Also it would be good for me if there is one more person who can reply and take my inputs in India time. If any debugging on board is required then it would be helpful.

  • 0 in reply to Abhishek Pratap Singh
    Guru 80055 points

    Hi Abhishek,

    There can be multiple reason why calibration can fail when sl_Start() is called. I know this two reasons for deployment at field:

    • calibration will fail when you are not able provide sufficient peal current for calibration
    • calibration can fail when you power on multiple devices at same moment at same location. RF interferences from calibration one device, can obstruct calibration of another device(s). I don't have this theory confirmed, but from logic of thing, calibration can be obstructed by strong RF interferences from other near devices (not only CC3220). But I think that issue can be worse with wrong RF design of device with CC3220 QFN.

    I think you should investigate your power rail for voltage drop during device startup (moment when is called sl_Start()). If issues is caused by RF interferences, you should wait for a few moments and after that call sl_Start() again.

    Migrating of whole SDK from older, may to be "pain in the ass", because newer SDK usually breaks compatibility of older code. But backporting of host driver and security fixes from newer SDK is relatively easy to do. Also ServicePack from latest SDK should be used. If you are still shipping new devices with ServicePack (3.13.0.3) from SDK version 3.30.01.02, this is very, very bad idea. It is likely that your device is affected by multiple know security vulnerabilities and some IOP issues. I think you should review your update policy from security standpoint, because your device at this state can be source of cyber security threats.

    Jan

  • 0 in reply to Jan D
    Intellectual 425 points

    Hi Jan,

    At max we run 4(interface level test) + 2(Functional test) + 2(OTA update devices) = 8 Devices in parallel on the production line and they are all close to each other(within WIFI range). But this placement has been similar for more than a year. Only now we have noticed this issue as it has become a blocker for production.

    Please do inform me for any additional information that you require from my side to resolve this quickly. Also if there is something that I can try with the devices like isolating them from others or any such thing for testing purpose.

  • 0 in reply to Abhishek Pratap Singh
    Guru 80055 points

    Hi,

    I don't have nothing more to say that I stated above. I think you should focus at two scenarios which I said above. You should also update your ServicePack. Do you use CC3220SF QFN, right?

    If you don't have this issue before, you need to determine what was changed (new assembly batch of PCBs, new batch of components, etc.). Nobody than you can do this investigation. This is your job.

    Let me know about results of your investigation what was changed.

    Jan