CC3220MOD: sl_Start() call gives SL_API_ABORTED error

Tunstall_User,

You should be able to call sl_stop() then sl_start() to handle this. Can you share a code snippet on how you are doing this? Are you doing it in the event handler?

Thanks,
Vince

Vince,

In the file 'platform.c' from the ti example code for tcpecho demo in simplelink_cc32xx_sdk_2_40_01_01 we have original code:


void mainThread(void *pvParameters)
{
 .........

    /* Turn NWP on - initialize the device*/
    mode = sl_Start(0, 0, 0);
    if (mode < 0)
    {
        Display_printf(display, 0, 0,"\n\r[line:%d, error code:%d] %s\n\r", __LINE__, mode, DEVICE_ERROR);
    }

    if(mode != ROLE_STA)
    {
        /* Set NWP role as STA */
        mode = sl_WlanSetMode(ROLE_STA);
        if (mode < 0)
        {
            Display_printf(display, 0, 0,"\n\r[line:%d, error code:%d] %s\n\r", __LINE__, mode, WLAN_ERROR);
        }

    .....
}

I changed this to:

void mainThread(void *pvParameters)
{
 .........

 /* Turn NWP on - initialize the device*/

    mode = -1;
    int result;

    while (mode < 0)
    {
        mode = sl_Start(0, 0, 0);
        if (mode < 0)
        {
            Display_printf(display, 0, 0,"\n\r[line:%d, sl_Start error code:%d] %s\n\r", __LINE__, mode, DEVICE_ERROR);
            result = sl_Stop(5000);
            if (result < 0)
                Display_printf(display, 0, 0,"\n\r[line:%d, sl_Stop error code:%d] %s\n\r", __LINE__, result, DEVICE_ERROR);
        }
    }

    .....
}

to reattempt the start procedure. The code was put in mainThread not the event handler as when sl_start() fails no connection events are generated thus no events handlers are run to put code in [as far as I understand things].

Are you saying a sl_stop()/sl_start() should have worked? even under SL_API_ABORTED errors?

Regards,

Vince,

I tried Ben's suggestion :

SL_UNSET_RESTART_REQUIRED;                                  ---> value 0x0900 before call, after this call g_SIDeviceStatus = 0x0800

.....

sl_stop()                                                                                  --> with g_SIDeviceStatus at 0x0800 this returns with -2018

....

sl_start()                                                                                --> returns -2004

There is one thing I haven't included in the original post and that was that programming with Uniflash has never failed, so far. This problem only seems to occur in the debugger. I didn't include this info at the time as I only thought to check it a few days later while having a similar problem in the debugger as described in :

https://e2e.ti.com/support/tools/ccs/f/81/p/777745/2877443#2877443

I did speak to a TI application engineer on Mon who said that the CC3220 module has 6 processors in it and the reset in the debugger only resets the ARM.

He suggested that the problem is due to the fact that the wifi processor is in an error mode which the debugger can't fix as it can't reset the wifi cpu. Using Uniflash to load a 'simple' program eg

tools\cc32xx_tools\servicepack-cc3x20\sp_3.10.0.5_2.0.0.0_2.2.0.6.bin

resets all the cpus as part of the flashing.

I have found that this does restore the wifi to working on the next run in the debugger but can fail again.

So it this 'problem' due to the inability of CCS8 to reset all the cpus in the CC3220 module?

Regards,

Hi,

If I may "short" comment.

I think inside your code need to be something significantly wrong. Few years ago I remember issue with CC3200 where one of e2e forum member was similar issue (failing in JTAG but code uploaded by Uniflash was functional). Reason was very prosaic - uninitialised variables. This variables had different values depending of type execution.

I use CC3220 is very extensive application and never seen such kind of failure as you. At 99% if something was not working properly, problem was at my side. I use CC32xx devices for a long time, longer than many members of App Team.

Full SoC reset is slightly tricky thing especially at older CC3200 devices. But at CC3220 devices is this fixed.

Jan

Jan,
As I mentioned aat the start of this post, to remove my code from the equation I reproduced the same problem in the tcpecho demo program from the the Texas sdk : simplelink_cc32xx_sdk_2_40_01_01

Looking at the the demo code and the 'Programmers Guide for the CC3X20' it looks to me it seems, remember I haven't used this chip before, to do as the guide says it should. There is very little code in this example where the wifi task is started so where should I be looking for this 'uninitialised variable(s)'?
This is important to us as if what you say is correct then potentially we could flash production code that may have this variable(s) set incorrectly and have random failures.

Regards,

Hi,

Unfortunately I have no experience with this particular demo. My experience is that some demo code in SDK is not that "bulletproof" than it should be. CC3220 devices are pretty good hardware, but at examples I see potential for improvement.

I am not sure what is causing your problem, but because you have issue on debugger, you should be able to determine what is going on.

There is one difference between execution of debugger and by the bootloader. After boot by bootlaoder are some peripherals already enabled. But this should not cause your issue.

Jan

Tunstall_User,

Just to confirm, the issue only appears when you debug the device? Try the following: Erase the MCU Image from the device - To do this, Flash a Uniflash project with the mcuimg blank. Now try to debug and see if you still see the error.

BR,
Vince

Vince,

I covered this 'solution' in an earlier response and using uniflash does restore opertion on the next debug session. Sometimes it continues to work a few times or sometimes 'ReLaunch' works but then it eventually gets into a mode where I have to use uniflash again.

As  a matter of interest, should I be using more care when stopping my application in the debugger, I normally use the red stop button ?

I have reproduced the text below of my earlier response:

He suggested that the problem is due to the fact that the wifi processor is in an error mode which the debugger can't fix as it can't reset the wifi cpu. Using Uniflash to load a 'simple' program eg

tools\cc32xx_tools\servicepack-cc3x20\sp_3.10.0.5_2.0.0.0_2.2.0.6.bin

resets all the cpus as part of the flashing.

I have found that this does restore the wifi to working on the next run in the debugger but can fail again.

Regards,

P. Holohan

Vince,
I forgot to mention that, yes, it is only seen during debug. So far I have not seen the problem when programming the chip using uniflash.

Regards,

Tunstall_User,

I dont see a reason you should be having this behavior. The only thing i can think of is when you reset the device using the debug feature in CCS, the NWP states are getting reset. To test this, I would first remove the image saved on serial flash like we already described, then every time you want to debug, power cycle the device beforehand.

Hope that helps,
Vince