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.

CC3235SF: Watchdog not resetting always (when using the network processor)

Part Number: CC3235SF
Other Parts Discussed in Thread: SYSBIOS, CC3200

Hi all,

I am using CC3235SF for making an IoT application. I am utilizing the Network processor to get the scan results using the following code:

if (!_initialized) {
        init();
    }

    const int WLAN_SCAN_COUNT = 30;
    int iRet;

    //
    // make sure the connection policy is not set (so no scan is run in the background)
    //
    iRet = sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION, SL_WLAN_CONNECTION_POLICY(0, 0, 0, 0), NULL, 0);
    if(iRet != 0)
    {
        sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION, SL_WLAN_CONNECTION_POLICY(1,1,0,0), NULL, 0);
        return 0;
    }

    uint32_t intervalInSeconds = 10; //min is 10 sec

    iRet = sl_WlanPolicySet(SL_WLAN_POLICY_SCAN , SL_WLAN_SCAN_POLICY(1,0), (uint8_t*) &intervalInSeconds, sizeof(intervalInSeconds));
    if(iRet != 0)
    {
        sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION , SL_WLAN_CONNECTION_POLICY(1,1,0,0), NULL, 0);
        return 0;
    }

    delay(900);  // wait for the net list

  
    SlWlanNetworkEntry_t found_networks[WLAN_SCAN_COUNT];
    //memset(&found_networks, 0, sizeof(found_networks)); 
    
    network_count = sl_WlanGetNetworkList(0, (unsigned char)WLAN_SCAN_COUNT, &found_networks[0]);
    //
    // disable scan
    //
    sl_WlanPolicySet(SL_WLAN_POLICY_SCAN, SL_WLAN_DISABLE_SCAN, NULL, 0);

    sl_WlanPolicySet(SL_WLAN_POLICY_CONNECTION , SL_WLAN_CONNECTION_POLICY(1,1,0,0), NULL, 0); //(1,1,0,0)
    return network_count;

and also another function in order to be called after the scan and print  the results for each network found from the list:

//function: for getting each SSID  for each net

if (!_initialized) {
        init();
    }
    //
    //get the network list and return the ssid of the requested index
    //
    if (networkItem >= network_count) {
        return NULL;
    }

    //
    //fetch all 20 items. For some reason, fetching a single item doesn't work
    //
    SlWlanNetworkEntry_t netInfo[network_count];
    
    memset(&netInfo, 0, sizeof(netInfo));
    sl_WlanGetNetworkList(0, network_count,   (SlWlanNetworkEntry_t*)&netInfo);
    strcpy(string_output_buffer, (char*)netInfo[networkItem].Ssid);
    return  string_output_buffer;
//===========================================
//function: for getting each BSSID for each net
if (!_initialized) {
        init();
    }
    //
    //get the network list and return the ssid of the requested index
    //
    if (networkItem >= network_count) {
        return NULL;
    }

    //
    //fetch all 20 items. For some reason, fetching a single item doesn't work
    //
    SlWlanNetworkEntry_t netInfo[network_count];
    memset(&netInfo, 0, sizeof(netInfo));
    sl_WlanGetNetworkList(0, network_count,  (SlWlanNetworkEntry_t*)&netInfo);    

    memcpy(string_output_buffer2, netInfo[networkItem].Bssid, BSSID_LEN);
    return  string_output_buffer2;

//=================================

//function: for getting the RSSI value for each net

if (!_initialized) {
        init();
    }

    //
    //get the network list and pull out the security type of the requested item
    //
    if (networkItem >= network_count) {
        return 0;
    }

    //
    //fetch all 20 items. For some reason, fetching a single item doesn't work
    //
    SlWlanNetworkEntry_t netInfo[network_count];
    memset(&netInfo, 0, sizeof(netInfo));
    sl_WlanGetNetworkList(0, network_count, (SlWlanNetworkEntry_t*)&netInfo);

    return (int32_t)netInfo[networkItem].Rssi;

For some reason, that I am still investigating, some times the code crashes while trying to get the netInfo scan list. 

Therefore, I am trying to incorporate the watchdog into my implementation in order to be able to reset the system when this happens.

I am using the driverlib/wdt.h and the watchdog in implemented as followed:

    //initialize the watchdog
    MAP_PRCMPeripheralClkEnable(PRCM_WDT, PRCM_RUN_MODE_CLK);
    MAP_WatchdogUnlock(WDT_BASE);
    MAP_IntPrioritySet(INT_WDT, INT_PRIORITY_LVL_1);
    MAP_WatchdogIntRegister(WDT_BASE,&WatchdogIntHandler);
    MAP_WatchdogReloadSet(WDT_BASE,MILLISECONDS_TO_TICKS(WD_PERIOD_MS));
    MAP_WatchdogEnable(WDT_BASE);
     ...
    //Wdt handler
    void WatchdogIntHandler(void)
    {
      MAP_WatchdogIntClear(WDT_BASE);

    }

However, the watchdog is showing unexpected behavior regarding the network processor (I tried it with a non-WiFi example and worked fine). In particular, if the code crashes, the reset is not always invoked by the watchdog. 

The watchdog resets both the MCU and the Network processor right? 

Is there any known issue regarding the watchdog working with the network processor?

Thanks a lot!

Artemis

 

  • Hi Artemis,

    The watchdog timer should work for NWP-based hard faults as well. Though, is there a reason why you're using raw driverlib to setup your WDT instead of using the Watchdog_*() APIs? Using the TI drivers instead of the raw driverlib is highly recommended as those APIs will simplify your code and ensure that there isn't any error in the setup of the WDT.

    When you say the code crashes when getting the netinfo list, exactly what happens? Does it look like the Wi-Fi host driver just hangs waiting for a sync object, or do you actually enter the hard fault handler? 

    Also, what do you mean that "the reset is not always invoked by the watchdog"? Does the WDT reset sometimes work for that NWP crash?

    Regards,

    Michael

  • Hi Michael,

    Thanks for the prompt reply. 

    The reason for using the Raw library is that we started using a simpler compiler for our project (not CSS) at first. When tried to use TI drivers API,  we had a hard time outside CSS due to the configuration of the device ( i.e. Watchdog_config & Watchdog_count were not set up properly  and also some mismatch between the two files "ti_drivers_config.h",  <ti/drivers/Board.h>  resulting to errors).

    How can I determine if I enter the hard fault handler? 

    Also, I would to ask regarding that, when calling again the sl_WlanGetNetworkList for getting respectively the SSID, BSSID and RSSI (without setting the policy scan as you can see in the above code snippets), is there going to be any memory issue? Or the program just gets the netInfo list from the previous scan (without actually performing a new scan)?

    Sorry for the multiple questions, but I trying to debug what exactly might cause the problem.

    Thanks a lot,

    Artemis

  • Hi Artemis,

    If you enter a hard fault and are using the debugger, you will notice if you pause execution that you're looping in a hard fault loop. You can also check the FAULTSTAT register for information. See my post here for how to check that: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/865780/3210205#3210205

    There shouldn't be any issue with memory management for repeatedly calling sl_WlanGetNetworkList(). Just in case though, you could collect NWP logs so that I can check and ensure there isn't any memory leak or similar from that command. You can follow the instructions here to do so:

    https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/874487/3241801#3241801

    Regards,

    Michael

  • Hi Michael,

    Thanks a lot for the suggestion. Looking at the debugger's value I can see the following:

    I can see also that sometimes when the program hangs, I get an HW exception at  system\kernel\tirtos\packages\ti\sysbios\family\m3\Hwi.c. 

    What does this imply?

    Thanks a lot!

    Artemis

  • Hi Artemis,

    You can take a look at the end of chapter 3 of the CC3220 TRM to decode those registers: http://www.ti.com/lit/swru465

    Taking a look for you, FAULT_STAT of 0x20000 = INVSTAT fault, HFAULT_STAT 0x40000000 = forced hard fault has occurred. Those two registers together mean that as your program was running, an instruction was executed that attempted to use the EPSR incorrectly. This is almost always due to memory corruption of some sort resulting in garbage data being executed as an instruction. As the TRM explains, you can check the PC value that is stacked for return from the Hwi loop to see which exact caused the failure. However, that's not a very useful exercise since the instruction is almost certainly a corrupt instruction that's meaningless.

    If you're using TIRTOS, a useful tool is the RTOS object viewer. You can access it using my instructions here: https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/p/733294/2707429#2707429

    With that tool, you can check the running state of the RTOS at the point of your hard fault. I suggest you take a look a the task stacks, and your heap memory to begin with. What do you see there?

    Regards,

    Michael

  • Hey Michael,

    Thanks for the suggestion. Looking at the PC value its a bit difficult to debug, but it seems that some instruction correlated to the NWP trying to connect again to the WiFi. I will also check the stack and come back to you about it.

    Also, for recovering from the watchdog reset, is this necessary and sufficient to be included at the start of the code, as the manual suggests? (Please see attached figure below p.360)

    Thanks again,

    Artemis

  • Hi Artemis,

    As I know that this code is not mandatory for CC3220 and CC3235 devices. It is mandatory for CC3200 devices only. But don't ask my, why is inside CC3220 and CC3235 TRM.

    Jan