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.

LAUNCHCC3220MODASF: Reset, device reset, and power cycle: Host, NWP, or both?

Part Number: LAUNCHCC3220MODASF


Hi,

I’d like to make sure I understand the terms used by SWRU455 concerning resets in relation to my CC3220MODASF.

When SWRU455 talks about the SimpleLink Wi-Fi device it means just the NWP and not the whole CC3220MODASF? For example, 2.1.1 Wi-Fi Connectivity says ‘Moving from mode to mode requires the user to reset the SimpleLink Wi-Fi device’.

Resetting the SimpleLink Wi-Fi device, AKA NWP, is as simple as sl_Stop() followed by sl_Start()?

3.8, MAC Address: ‘Setting a MAC address takes effect only after reset’. So sl_Stop() + sl_Start()?

3.12, Persistent Configuration, If system-persistent configuration is false, ‘configurations revert to default after reset’. So sl_Stop() + sl_Start() causes that reversion?

3.14, Errors, SL_DEVICE_EVENT_FATAL_DRIVER_ABORT, ‘User must perform device reset’. Is a ‘device reset’ different to the above sl_Stop/Start() resets?

4.9.1, 2.4-GHz Wi-Fi Calibration Modes, SL_ERROR_CALIB_FAIL, ‘For a calibration error with Normal or Triggered calibration, power/hibernate cycle invokes recalibration’. What needs its power cycling on a CALIB_FAIL? Is it the NWP/MAC/PHY, or must it include the Host?
out_of_box/provisioning_task.c handles CALIB_FAIL by calling mcuReboot() which says in its comment ‘reboot the M4 host processor’, stops the NWP with sl_Stop(), and then calls PRCMHibernateCycleTrigger() which hibernates after telling the RTC to wake it up imminently. So it’s implying the Host needs its power cycled, and has stopped the NWP so that too will have its power cycled?

Why doesn’t out_of_box above call PRCMMCUReset() instead? What’s the difference? Does PRCMMCUReset() reset only the Host M4, and optionally its SysTick, NVIC, and SCB peripherals? Whereas CALIB_FAIL needs the NWP M3 or something downstream of it to by cycled?

Can the Host be left unharmed, not reset, yet still reset the NWP or whatever else needs the power cycle to start recalibration?

Cheers, Ralph.

  • Hey Ralph,

    You can find my response to all your questions below:

    When SWRU455 talks about the SimpleLink Wi-Fi device it means just the NWP and not the whole CC3220MODASF?

    What you read in this document applies to all CC3X20 and CC3X35 devices and both MOD(A) and non-MOD. I wouldn't say just NWP because there is a host driver component referenced many times that has to do with the application MCU.

    Resetting the SimpleLink Wi-Fi device, AKA NWP, is as simple as sl_Stop() followed by sl_Start()?

    Yes. That is correct. 

    MAC Address: ‘Setting a MAC address takes effect only after reset’. So sl_Stop() + sl_Start()?

    Correct.

    Persistent Configuration, If system-persistent configuration is false, ‘configurations revert to default after reset’. So sl_Stop() + sl_Start() causes that reversion?

    Correct. What this is saying is that all system persistent configurations are set to true. Meaning on an NWP restart any settings you have made will remain persistent. However, if you set a system-persistent configuration to false, then any changes you make to settings in appendix B will revert back to default values on an NWP reset.

    Errors, SL_DEVICE_EVENT_FATAL_DRIVER_ABORT, ‘User must perform device reset’. Is a ‘device reset’ different to the above sl_Stop/Start() resets?

    No. sl_Stop/sl_Start as you know resets the NWP but also the host driver running on the MCU. 

    So it’s implying the Host needs its power cycled, and has stopped the NWP so that too will have its power cycled?

    That is correct. 

    Why doesn’t out_of_box above call PRCMMCUReset() instead? What’s the difference?

    PRCMMCUReset is just a SW reset whereas PRCMHibernateCycleTrigger is a clean reboot of the device. I would imagine there's some extra things that need to be cleaned up that a SW reset is just not enough when it comes to SL_ERROR_CALIB_FAIL but I'm not too familiar with the inter-workings of that. If you have any more specific questions to SL_ERROR_CALIB_FAIL let me know and I can find out.

    Hope this helps!

    Jesu

  • Hi Jesu,

    Thanks for taking each question in turn, the replies were very useful. In particular, that sl_Stop+sl_Start is resetting the host driver as well as the NWP, something I hadn't considered.

    I've one question left. It's what started me realising I wasn't sure of the various distinctions...

    Can the Host be left unharmed, not reset, yet still reset the NWP or whatever else needs the power cycle to start recalibration?

    Calibration seems such a wireless-related side of things, I just want to make sure its impact does need to ripple all the way back up to the Host processor. I've plumped for Triggered recalibration rather than Normal which will lessen the impact a bit.

    Cheers, Ralph.

  • Hi,

    Just a comment...

    Thanks for taking each question in turn, the replies were very useful. In particular, that sl_Stop+sl_Start is resetting the host driver as well as the NWP, something I hadn't considered.

    No. This statement is not 100% correct. Calling sl_Stop()+sl_Start() API is not able to recover driver at all cases.

    Jan

  • Hey Ralph,

    At a high level, the host driver can be thought of as an application protocol that runs on the MCU and allows it to communicate with the NWP. Calling sl_Start opens an instance of that host driver and sl_Stop closes this instance. One thing I want to add however is when you call sl_Stop, the NWP actually goes into hibernate mode which is effectively a power cycle. With that in mind....

    Can the Host be left unharmed, not reset, yet still reset the NWP or whatever else needs the power cycle to start recalibration?

    This is a good point. I tend to agree with your thought process here. It does not make sense to have to have to reboot the entire device (MCU + NWP) when calibration is only relevant to the NWP. When describing the calibration error the programmer's guide quotes: "power/hibernate cycle of the network subsystem" in one of its mentions. I have reached out to the developer who wrote the out_of_box demo so we may understand better why he resets both the NWP and MCU. 

    Jesu

  • Ralph,

    I just heard back from the developer and he believes an NWP power cycle should be sufficient to trigger a re-calibration (sl_Stop/sl_Start). Hope this answers all your questions/concerns.

    Jesu

  • Hi Jesu,

    It does indeed, thanks for making the effort to find out. Just an NWP cycle makes it much easier to deal with.

    Ideally, the out_of_box demo will change its handling of SL_ERROR_CALIB_FAIL to match as I searched the SDK source tree for the error as a guide and others might do the same.

    Thanks again.

    Cheers, Ralph.