CC3235S: How to software reset

Are you doing OTA update?

how did you install the code? Programming to the SFLASH through uniflash, or using CCS debugger?

Please explain you use-case in details.

I believe the issue is not with reset itself but with the new image that is supposed to run afterward. 

Hi,

No, This is not an OTA update.

A custom board using CC3235S is used, and SFLASH is programmed through Uniflash. 

Since HW Reset is missing as an external pin in the HW design of the custom board, I'm going to use Software Reset using GPIO Interrupt so that the user can reset the module. I'm not trying to run a new image, I'm trying to run an existing image.

I even checked that the GPIO callback function works on the falling edge of the GPIO, and I called MAP_PRCMHibernateCycleTrigger() or MAP_PRCMMCureset() in the callback function, but it does not restart.

Hi,

Is your interrupt handler properly designed to prevent re-entring (e.g.contact bouncing)? If not, you need fix this bug of your code (e.g. disabling interrupt from GPIO at beginning of ISR handler).

Jan

Hi,

I didn't consider to prevent re-entring. As your advise, I added GPIO_disalbeInt() API at beginning of my callback function.

void softResetGPIOCallback(uint8_t index)
{
    GPIO_disableInt(CONFIG_GPIO_CTS);
    UART_PRINT("\n\rDetect Falling trigger at CTS Pin!!\n\r");

    sl_Stop(SL_STOP_TIMEOUT);

    MAP_PRCMMCUReset(1);

    return;
}

But, It still does not restart after calling the MAP_PRCMMCUREset() API. (after call it, all operation is stopped)

Could you give me some advice on software reset?

Hi,

At my code I use reset with SoC hibernation which works by similar way as API PRCMHibernateCycleTrigger(). My code is:

  MAP_PRCMHibernateIntervalSet(330);
  MAP_PRCMHibernateWakeupSourceEnable(PRCM_HIB_SLOW_CLK_CTR);
  MAP_PRCMHibernateEnter();

Calling of sl_Stop() API from interrupt context is generally not a best idea. Safer way is just set event at the ISR handler and handle reset at thread.

Jan

Thank you for advice.

As your advice, I create thread to monitor reset event, and ISR handler is set event. (in reset thread, I call sl_stop() and PRCMHibernateCycleTrigger() when set event)
But, it is not works too.

However, If run after except sl_stop(), reset works! But, I don't know why.

Hi,

When you call unblock your reset thread it does stuck inside sl_Stop() API?

Jan

Yes, It does stuck inside sl_Stop() API

Also, sl_WlanDisconnect() API too. (If connected to AP, this api call)

Hi,

There need to be something else wrong inside your code. There is no reason to stuck inside sl_Stop(). YOu need to have issue like crashed host driver, stack overflow, task priority issue or something like that. But it is hard to say what.

Jan

Hi,

That issue seems difficult to pinpoint the cause.

However, when sl_Stop() is not used before calling PRCMHibernateCycleTrigger(), Reset is performed.

Are there any issues to consider when resetting the network processor without stopping it?

Hi,

I think main reason is to prevent to SPI flash corruption when write operation is under progress.

But I think state when sl_ APIs are freezing at your case is not a good state. I think you need investigate this issue unless you want to release very unreliable product.

btw... do you have updated latest ServicePack inside device?

Jan

Thank you for reply.

I used SDK 6.10 and service pack 4.13

In addition to what Jan mentioned, sl_Stop is required after an OTA (i.e. if you updated the MCU image file) to enter the device into a test mode, before the reset. but this is not relevant for you currently.

Have you gone through the hardware review process? https://www.ti.com/tool/SIMPLELINK-WIFI-DESIGN-REVIEWS

We had couple of issue with sl_Stop, but not in the last year or two. So if you are using latest driver and SP, this is not expected.

Are there other threads running in parallel to the one that triggers the reset? if yes, what are they doing?

It is recommended to disable all interrupts (Hwi_disable()) before calling the PRCMHibernateCycleTrigger().

Hi,

After several tests, we got the following results.
If sl_Stop() is called for Reset in the main thread created in main_tirtos.c, sl_Stop does not stuck inside. However, when sl_Stop() is called on the resetMonitor thread created in the main thread, it does stuck inside. (The resetMonitor thread is driven by the event that occurred in the GPIO callback, and stops all interrupts in the GPIO callback.)

In the situation where the resetMonitor thread is running(when sl_Stop does stuck inside), the main thread does the command parsing and handle in the while loop for the User Command Interface.

Hi,

There should not be any particular reason for such issue with calling sl_Stop() from your resetMonitor thread.

Few questions:

• I suppose that you are using TI-RTOS. Right? Which versions (SYS/BIOS 6 or TI-RTOS7)?
• What are you doing at your main thread? Do you call there sl_ API calls when you are processing your user command Interface? What sl_ API calls are at that thread? Do you use socket APIs at this thread? Do you use blocking or not blocking sockets?
• How are set priorities for threads (resetMonitor, main thread, sl_Task)?

Jan

Hi,

• I suppose that you are using TI-RTOS. Right? Which versions (SYS/BIOS 6 or TI-RTOS7)?

Yes, I'm using TI-RTOS. my project is based on <sdk path>\examples\rtos\CC3235S_LAUNCHXL\demos\network_terminal\tirtos\ccs. 

• What are you doing at your main thread? Do you call there sl_ API calls when you are processing your user command Interface? What sl_ API calls are at that thread? Do you use socket APIs at this thread? Do you use blocking or not blocking sockets?

When handling the user command interface, use the sl_* API according to the command, and when using the socket-related Connect command, end the user command interface and create a socket thread for data processing.

However, I did not use the sl_* APIs in the user command interface because we did not use any commands in the test situation mentioned above.

In the initialization process, SlNetConn_init(), WiFi_IF_init(), and OTA_IF_init() were performed.

To be more specific, my project used the sl_* API, but the SlNetConn API is also used to use the OTA_IF module. Change the connection related to the slNetConn API, and use the existing sl_* API for the rest of the functions.

• How are set priorities for threads (resetMonitor, main thread, sl_Task)?

Threads are main thread, sl_Task, workQ(in create OTA module), SlNetConn_process, SlWiFiConn(in create WiFi moudle), UART read, LED display, ResetMonitor.

The priorities are as follows.

main thread: 1

sl_Task: 9

workQ: 2

SlNetConn_process: 1

SlWiFiConn: 9

UART read: 7

LED display: 5

resetMonitor: 7

When using the SlNetConn_process, it is recommended to call SlNetConn_Stop before calling sl_Stop.

Otherwise there can be race conditions that can cause issues to the SlNetConn module.

I don't think sl_Stop should get stuck though.

In general i suggest that you make sure the closure/reset is performed in the opposite order of the init sequence.

Hi,

Called SlNetConn_Stop before calling sl_Stop.

But so is it.

Stuck inside sl_Stop or sl_Wlandisconnect. And it gets stuck inside SlNetConn_Stop after connected to WiFi (sl_Wlandisconnect is called inside SlNetConn_Stop)

OTA upgrade is implemented in the user command interface I have implemented, and it is implemented using the OTA_IF module. If OTA install is possible, it calls the OTA_IF_install() API, without getting stuck inside sl_Stop.

It is probably expected that it is a problem in the code I implemented, and the cause is unlikely to be found in a short time.

Yes, the only thing i can suggest now is that you send an NWP log (see chapter 20 in the programmer's guide) and i'll check if i can see anything.

Theoretically there should be any difference when calling the sl_Stop from different threads. Just make sure that the non-main thread is really a thread (i.e. that the code is not executed from an interrupt context) -but according to your description it should be ok.

Hi,

My code is call sl_Stop in thread not interrupt context.

...
void * mainThread(void * arg)
{
    GPIO_setCallback(CONFIG_GPIO_SOFTRESET, resetGPIOCallback);
    GPIO_enableInt(CONFIG_GPIO_SOFTRESET);
    ...
    pthread_t resetMonitorThread;
    softResetThread = OS_createTask(7, 256, resetMonitorThread, NULL, 0);
    ...
}
...

void resetGPIOCallback(uint8_t index)
{
    GPIO_disableInt(CONFIG_GPIO_SOFTRESET);
    UART_readCancel(uartHandle);
    HwiP_disable();
    DBG_PRINT("\n\rDetect Falling trigger at CTS Pin!!\n\r");

    gSoftReset = 1;

    return;
}
...

void * resetMonitorThread(void* arg)
{
    while(1)
    {
        usleep(100000);

        if (gSoftReset)
        {
            SlNetConn_stop(SlNetConnEventHandler);
            DBG_PRINT("1\n\r");
//            sl_WlanDisconnect();
//            DBG_PRINT("2\n\r");
//            sl_Stop(SL_STOP_TIMEOUT);
//            DBG_PRINT("3\n\r");

            DBG_PRINT("reseting the platform...\n\n\n\r");
            MAP_PRCMHibernateCycleTrigger();
        }
    }
}

Below is NWP logs by case.

"10.28_reset_without_slstop" : it is only call MAP_PRCMHibernateCycleTrigger() in resetMointor thread. it works reset

"10.28_reset_with_slstop" : it is call sl_Stop() before MAP_PRCMHibernateCycleTrigger(). get stuck.

"10.28_reset_with_slwlandisconnect" : it is call sl_WlanDisconnect() before MAP_PRCMHibernateCycleTrigger(). get stuck.

"10.28_reset_with_slnetconnstop" : after connect to AP, it is call SlNetConnstop() before MAP_PRCMHibernateCycleTrigger(). it works reset.

"10.28_reset_ota" : it does ota upgrade using OTA_IF. it works reset and ota commit. (new image's baudrate is not 921600bps. so, log isn't wrote after ota.)

10.28_cc3235s_logs.zip

If connected to an AP, it seems to call sl_WlanDisconnect() inside slnetconn_stop(), but not sl_Stop.

Is it ok to not call sl_Stop() before MAP_PRCMHibernateCycleTrigger()?