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: Do we need to call sl_Stop before issuing a hibernate cycle?

Part Number: CC3200


Hello everyone,

Three years ago we were unsure of the correct way of using sl_Stop in our hibernate cycle routine (see related post from 2015). We ended up calling sl_Stop(0) before actually issuing the hibernate cycle in order to shut down the NWP before rebooting. This seemed to work flawlessly until today. The most recent hibernate routine is as follows:

void app_utils_hibernate_cycle (bool slstop, bool signal_fatal_error)
{
	if (signal_fatal_error)
	{
		// Signal fatal error
		LED_set_sys_flag(LED_sys_flags_fatal_error, true);
		vTaskDelay(2000 / portTICK_PERIOD_MS);
		LED_set_sys_flag(LED_sys_flags_off, true);
	}

	taskDISABLE_INTERRUPTS();

	if (slstop)
	{
		sl_Stop(0); // Stop network processing
	}

	Utils_TriggerHibCycle(); // REBOOT !
	
	taskENABLE_INTERRUPTS(); // Should never reach this line
}

Note that we always set slstop parameter to true if sl_Start has been called previously.

We recently added the call to taskDISABLE_INTERRUPTS in order to prevent IRQs from hitting after a hibernate cycle is issued, as this also seemed to hangthe system for some reason. At first it seemed to solve the problem, but lately we've been experiencing a lot of system hangs right after we call app_utils_hibernate_cycle.

What is very strange is that the watchdog does not reset when this happens.

After a little debugging we realized that the problem might be the call to sl_Stop(0). We even tried the following:

void app_utils_hibernate_cycle (bool slstop, bool signal_fatal_error)
{
	if (signal_fatal_error)
	{
		// Signal fatal error
		LED_set_sys_flag(LED_sys_flags_fatal_error, true);
		vTaskDelay(2000 / portTICK_PERIOD_MS);
		LED_set_sys_flag(LED_sys_flags_off, true);
	}

	taskDISABLE_INTERRUPTS();

	if (slstop)
	{
		sl_Stop(0); // Stop network processing
	}

	while(1)
	{
		UARTCharPut(UARTA0_BASE,'\n');
		UtilsDelay(80000);
	}

	Utils_TriggerHibCycle(); // REBOOT !
	
	taskENABLE_INTERRUPTS(); // Should never reach this line
}

A few newlines are printed and then the system hangs for indefinite time.

We suspect that if Utils_TriggerHibCycle is reached directly after calling sl_Stop(0) the hibernate cycle works fine, but it there anything delays it (an interrupt or anything else) we reach this condition where the system hangs and the WDT cannot recover it.

We are inclined to remove the call so sl_Stop altogether, since apparently the hibernate cycle puts the NWP in a reset state. Do we really need to shut down the NWP before hibernating?

  • Hi Caio,

    It is recommended to call sl_Stop() with a timeout in order to allow the NWP to finish activities in progress and safely shut down before the MCU is placed into hibernate. Please try sl_Stop() with a parameter of 100 or 200 instead of 0.

    Additionally, please share the servicepack version you are using.

    Best,

    Ben M

  • Hello Ben, the same thing happens with a timeout of 200.

    We are using Service Packs 1.0.0.10.0 and 1.0.1.11-2.9.0.0. The issue is present with both.

    We removed the call to sl_Stop and everything seems to work flawlessly.

    The reason why we introduced the call to sl_Stop was to shut down the NWP before hibernating, but I now fail to see the point in doing this since hibernate also reboots the NWP (am I right?).

    Do you know if we can safely remove the call so sl_Stop before hibernating?

    Thank you.

  • Hi Caio,

    I understand that you see this working for you. I notice you have another thread on this topic here:
    e2e.ti.com/.../2827352

    The point of stopping the network processor first is to ensure a graceful shutdown if there are operations that need to complete (either internal to the NWP or ones the host MCU is wating on). Shutting it down with a timeout is a recommendation, but ultimately the design is up to you.

    In your case, I recommend digging into why the sl_Stop() call causes the system to hang. I would like to see logs from the network processor and a calls stack where the system hangs to understand what is happening.
    processors.wiki.ti.com/.../CC3100_&_CC3200_Capture_NWP_Logs

    Best,
    Ben M
  • Hi Benjamin, sorry for creating two threads, at first we didn't realize it was the same issue. I'll be posting to this one from now on.

    I'll get the logs tomorrow and post them here.

    Thank you.

  • Hello Bejamin,

    We are calling app_utils_hibernate_cycle as a software issued reboot for the following scenarios:

    - Reboot to recover from unexpected software errors (for example: sanity check not met, could not initialize a FreeRTOS object, etc.). We replaces all while(1) from TI's code with app_utils_hibernate_cycle (better to reboot and try again than to hang the system on a busy loop).

    - Reboot if we could not initialize an external IC (we just try again on next boot...)

    - Several routines are protected by timeouts. They usually start a soft timer (from FreeRTOS), which should be stopped just before their finish. If the said routine hangs for any reason or take much longer than expected the soft timer will issue a hibernate cycle.

    - After a successful OTA download: (status & (OTA_ACTION_RESET_MCU | OTA_ACTION_RESET_NWP))

    -------------


    The NWP log bellow was taken by issuing a hibernate cycle one minute after boot (issued by a soft timer). In order to reproduce the issue, I altered app_utils_hibernate_cycle:

    void app_utils_hibernate_cycle (bool signal_fatal_error)
    {
    	if (signal_fatal_error)
    	{
    		// Signal fatal error
    		LED_set_sys_flag(LED_sys_flags_fatal_error, true);
    		vTaskDelay(2000 / portTICK_PERIOD_MS);
    		LED_set_sys_flag(LED_sys_flags_off, true);
    	}
    
    	taskDISABLE_INTERRUPTS();
    
    	sl_Stop(0); // Stop network processing
    
    	while(1)
    	{
    		Message("\n");
    	}
    
    	Utils_TriggerHibCycle(); // REBOOT !
    	
    	taskENABLE_INTERRUPTS(); // Should never reach this line
    }

    Note that the WDT should reboot the system because of the while(1), but nothing happens. If we remove sl_Stop(0) the WDT reboots the system as expected.

    NWP Log:

    NWP_log.tar

    Please tell me if I captured the log correctly.

    Thank you.

  • Hi Caio,

    The log does not look quite correct. Can you double check the connections to the pin/GND, the baudrate of the terminal that you are using, and make sure you are logging the data in binary mode. Also, if possible, make sure you are collecting before the network processor boots up and try to capture a little longer period of activity.

    Best,
    Ben M
  • Hi Benjamin, I was trying to capture the data on Linux with grabserial, apparently it does not work with binary data.

    I switched to Windows to use Teraterm, I also started capturing before supplying power to the device. Here's what I got: NWP Logs.tar

  • Hi Caio,

    The captures, unfortunately, still do not look good. It's odd because I can see some of the expected data when I examine the log manually, but the full thing doesn't parse correctly and I'm not seeing the info I need. I'm reviewing the data a bit more to see if I can give some specific recommendations for recapturing. Until then, can you confirm that with Tera Term you have all the expected settings like the baudrate of 921600?

    Best,
    Ben M
  • Hi Benjamin, I tried once again making sure the baud rate is 921600. Can you please check?

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/968/nwp_5F00_log.7z

    Thank you.

  • Hi Caio,

    This capture looks complete. I am reviewing and will let you know if it indicates what could be happening.

    Best,
    Ben M
  • Hi Caio,

    Everything in the logs from the network processor look fine. I see one reset about 2/3s of the way through the file after which it looks like the network processor is restarted and then reconnects to the AP and operation continues. After that, the logs stop some time later while the device is idle. I assume this is when the last sl_Stop() was called and you see the system hang?

    Since I don't see any issues in the logs, this indicates to me that the investigation should be into what is happening with the state of the application/RTOS which could cause a hang. Especially since in your previous tests you were able to see the code reach and iterate through this loop a couple times before it hangs:

      while(1)
        {
            UARTCharPut(UARTA0_BASE,'\n');
            UtilsDelay(80000);
        }

    A couple more things that would be interesting to see is if you can test on a LaunchPad the same sequence with the servicepack you are currently using in your system (looks like v2.4.0.2). Do you see the same hanging behavior? 

    Have you tested a more simplified version of your application (with tasks removed) where you were simulating the reset trigger (with a timer interrupt) and seen this sequence cause the system to hang?

    Best Regards,

    Ben M

  • Hi Ben, actually the first reset you see is probably the call to sl_Stop. I left the log running a while after the call to sl_Stop (when the MCU hangs) because I could still se data coming in. I stopped logging after an arbitrary time.

    Shouldn't the NWP be turned off after sl_Stop? Why did it reset and connect again instead of staying off?

    What is very strange to me is that the watchdog is apparently unable to reset the MCU in this condition. We do not have an interrupt handler for the WDT interrupt, we just let the WDT reset the system after expiring twice, so I'm sure the WDT is not being reset.

  • Hi Caio,

    Yes, the logs should stop if the network processor is not enabled (as should be the case after the sl_Stop call). This indicates to me that somehow the NWP is being enabled again after the stop attempt.

    Can you try a simplified test in your code where you call sl_Stop() and set a breakpoint afterward to make sure you see the device and logs stop in a good case?

    Thanks,
    Ben M
  • Hi Caio,

    Any update here?

    Best,
    Ben M