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.

CC3200: Resetting the WiFi coprocessor

Other Parts Discussed in Thread: CC3200

Hey everyone,

For the project I'm working on, it is important that the application works correctly even when it is loaded using a debugger without resetting the CC3200 completely. 

An issue I have been having, is that initializing the SimpleLink subsystem does not always work, depending on the state of the system when the application was loaded.

An example: if I have a certain application running, then a JTAG debugger takes control of the CC3200 and loads my application, the application will get stuck infinitely on sl_Start(...). The same application always works when there is no application running on the CC3200 at the time the debugger connects to it. Presumably, the reason for failing in the former situation is that the SimpleLink subsystem was already in a certain state by the time my application started.

Is there any way to reset the CC3200's peripherals and especially the SimpleLink coprocessor, upon starting my application? For example, could I use PRCMMCUReset() or PRCMPeripheralReset()? Do these functions reset the coprocessor as well? And if so, how might I use PRCMMCUReset() on starting my application, yet avoid getting in an infinite reset loop?

In my situation, the debugger first performs a full system reset. Then, after some time (during which the CC3200 bootloader may already "screw up" the system state) the debugger halts the user core, and performs a local reset on the user core, halting the core upon coming out of this reset. So when my application starts, the user core is fully reset but the peripherals and WiFi coprocessor may not be.

  • Hi Sander,

    Did you put the SOP2 jumper while working with debugger?

    Regards,
    Ankur
  • Hi Ankur,

    The thing is that I need write access to the serial flash from the program being debugged.

    My workaround so far has been as follows:
    - place the SOP2 jumper on FLASH
    - reset the device and connect debugger to it
    - remove the SOP2 jumper
    - load and execute the program using the debugger

    This has worked great. If I just reset the device without placing the SOP2 jumper, I get problems running sl_Start(). Is there any way to ensure proper startup of the network coprocessor, when the hardware is in an unknown state at the time the program starts?

    FYI: the reason why I need this to work is that the program which is loaded onto the target acts as a proxy, allowing the debugger to access flash memory by issuing commands to it.

    Thanks!
  • Hi Ankur,

    Maybe I have misunderstood the operation of the SOP pins.

    If the SOP2 header is connected (UART/flash mode), after which I connect using a debugger, and load+run a program, would that program have full access to the external flash using the SimpleLink API's (sl_FsOpen(), sl_FsRead(), sl_FsWrite() etc)?
    If so, then there is no reason for me to remove the SOP2 header at all.

    Kind regards,

    Sander
  • Hi Ankur,

    There was a bug in my code causing me to believe I needed to remove the SOP2 header to get flash access working, but I've now confirmed that I can just leave the SOP2 header on and everything works great.

    Thanks!