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.

CCS/CC3220SF-LAUNCHXL: Out-of-the-blue "Error -2131 @ 0x0" despite nothing changing.

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF, UNIFLASH

Tool/software: Code Composer Studio

 Out of the blue, after making routine code changes, I started getting the dreaded "Error -2131" popup as per the attached screenshot.

Cycling power (by unplugging the USB cable to the LP board) and even the whole PC does not clear the problem.

I also tried a second second LP board with its own USB cable and a different USB port on the PC.

My code uses the "__SF_DEBUG__"  technique, but I've been using that for months. It does, however, appear (based on LED activity) that the latest code changes have made it to the internal flash (unplugging/reconnecting the USB cable shows it running).

I went back to TI's gpiointerrupt_CC3220SF_LAUNCHXL_nortos_ccs project and now get "Error -2131" there.

Is there something my code could have somehow done on the board to make it "deaf" to CCS' efforts to connect to it? If so, how do I "clear" things? I also fired up UniFlash only to find that it does not appear to be able to identify the board!

  • Hi

    Can you check to ensure the board is in development mode?
    Also ensure you have the right SOP pin configuration

    Regards,
    Charles O
  • OK, I figured out a way to un-"brick" my CC3220SF Launchpad boards:

    Using UniFlash (4.2.1.1562):
    New Configuration (CC32230 LP/Serial)
    Start Image Creator
    Manage Projects / Recent Projects / OOB_SF_freertos
    Connect
    Program Image (Create & Program)

    USB cable -- DISCONNECT and RECONNECT --- this is essential

    CCS (7.3.0.00019 ):
    Select my (__SF_DEBUG__-enabled) project
    Debug (which I have configured to do a Target Reset which is reflected in CCS "Console" window)
    Start TeraTerm
    Resume (green triangle)

    Interestingly, the first call to MAP_PRCMSysResetCauseGet returns 0x00000007 (PRCM_HIB_EXIT) [with PRCMHibernateWakeupCauserGet returning 0x00000002(PRCM_HIB_WAKEUP_CAUSE_SLOW_CLOCK], instead of 0x00000002 (PRCM_POWER_ON) which I expected. I will ask about this in a new thread.

    So, TI, what's going on here?

    Also, TI, why can't we have a comprehensive UniFlash V4 User Manual, instead of a couple of thin "Getting Started" documents and the limited/confusing Image Creator manual? Given what UniFlash v4 appears to be CAPABLE of doing, I would expect such a manual to be SEVERAL HUNDRED pages long, including a long chapter on recommended development practices, particularly for those (like me) who lack expertise in security certificates. As others have commented, what info there is seems to be scattered all over the place, with much of it out of date and/or awash in errors/omissions.

    For what it's worth, why should we have to worry about security anyway during the prototyping phase when everything is still in the lab?

    I waste far too much of my time tearing my hair out and beating my head against the wall trying to make real progress. If I were calling the shots on the several CC32XX projects I've worked on recently, I would be recommending dumping TI and using something else. Based on posts by others on this forum, it's obvious that I'm not alone.
  • Both boards are in development mode and SOP[2:0] on both is 010. This has been working (adequately) for months and not changed.

    See my response to my initial post which apparently "crossed in the mail" with yours a few minutes ago.
  • Hi,

    Were you able to review the uniflash document linked below, it contains more information than the getting started guide
    www.ti.com/.../swru469a.pdf

    The reason security is needed is because it is a feature of the part, loading the certificate is required for flashing by design. However customers can debug their code in the lab using CCS when the device is in development mode.

    Regards,
    Charles O