• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 52 subscribers
  • Views 391 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2640R2F: Standby: Low-Speed Clock Source Invalid

Hester Corne
Intellectual 790 points
Part Number: CC2640R2F

Hi, 

In order to save power in my application I need to put the device into standby mode.  Following the steps in Table 6-6 in the reference manual I set the clock source for the HF and LF clocks before entering standby.  In order to resume the same state when exiting standby, I first use OSCClockSourceGet to save the current value and later call OSCClockSourceGet with those values.  I'm doing this for both the high speed and low speed clocks, and both are coming back with OSC_RCOSC_HF.  I was under the impression from Table 6-5 that it was not possible for the low-speed clock to use the RCOSC_HF source.  My application was originally based on the simple peripheral example and has not made any modifications to default clock sources and I'm running bare metal at this point in the application.

The reason this has come to my attention is that when I call OSCClockSourceSet with my saved value after exiting standby, the device seems to go into some unknown state and stops being responsive until a hard reset is performed.

Please could you explain why I'm getting a seemingly invalid clock source before entering standby?  And if setting the low-speed clock source to RCOSC_HF after exiting standby causes my device to crash, why doesn't it crash before that point?

Thanks,

Hester

  • 0
    TI__Guru 58425 points

    Hi Hester,

    Are you not using TI-RTOS or NoRTOS in your application? If you do, standby mode is handled by the power driver behind the scene and nothing you need to worry about in terms of taking extra code steps. 

  • 0
    TI__Guru 56590 points

    Hello Hester,

    We generally do not support bare metal implementations on e2e.

    https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz/f/156/p/641000/2364666#2364666

    You mentioned "My application was originally based on the simple peripheral example". Power saving is enabled by default in simple_perpheral and will enter standby with the help of the power driver and idle thread.

  • 0 in reply to Eirik V
    Intellectual 790 points

    Hi Eirik,

    I have a safety-critical part of my application that runs before RTOS is started, and it's during that time I want to enter standby.  Once RTOS is up and running I'm using the built in power management for standby/shutdown behaviour.

    Interestingly I have just tried porting the code into an application with no RTOS at all and can see the low-speed clock source is coming back as expected.  Is there something set up by XDC that could be changing the low speed clock source?  I have the low-speed clock source set to the default configuration as per that link you sent but if it's being overridden by XDC at startup that could explain why I'm not seeing what I expect...

    Thanks,

    Hester

  • 0 in reply to Hester Corne
    TI__Guru 58425 points

    Hi Hester,

    I suggest you study the "Power_sleep()" function found inside the power driver (PowerCC26XX.c) if you have not already. You will find that the only clock source that is manually forced of when going into standby it XOSC_HF if that is in use. In the case where RCOSC_HF is in use, you don't really do anything, you just make sure power domains is of and go into "deep sleep" using the "PRCMDeepSleep()" API. There is a bit more considerations but these are quite clearly commented in the "Power_sleep()" function I suggested above.

    The deep sleep API will effectively gate the HF clock. It is only in case of the XOSC_HF being used extra steps are taken, this as we need to actually turn this of to save on power and to do that we need to first switch to RCOSC_HF. 

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 790 points

    Hi M-W,

    I actually started with a copy of this function with the RTOS-specific bits commented out and it was all working as expected.  I was trying to understand why each step is performed and whether the order was important when I noticed a few steps in the manual were missing.

    I am able to successfully enter and exit standby if I leave the low speed clock alone, I'm just curious as to how it's coming back as RCOSC_HF instead of RCOSC_LF.  

    Thanks,

    Hester

  • 0 in reply to Hester Corne
    TI__Guru 58425 points

    Hi Hester,

    It could look as you get "RCOSC_HF" in both cases, this as "RCOSC_LF derived from HF" has the same value. Note that "RCOSC_LF derived from HF" also means that standby is not an option.

    What is done in the general example, and what you likely are missing in your solution to support standby mode, is the initial shift to the expected LF source. The Power driver does this during Power_init() where it checks which source is expected to be used and switches to this for LF. There is a few steps to this as there is clock qualifying going on etc. (you also need to turn of clock loss detection during the switch, it is all in there in the driver if you poke around). 

    From the point where you are running on the expected LF source, which need to be the LF XOSC or RCOSC to support standby mode, you should be good to go. Also note that the steps in the manual was not "missing", they are not needed as the driver knows that for this function to be invoked, the LF source is one of the allowed. It thus only need to check if XOSC_HF is being used as RCOSC_HF is perfectly fine in standby mode.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 790 points

    Hi M-W

    OK that makes some sense.  In my application I am never using the external oscillator before I'm entering standby so it will always be the RC oscillator, so technically I wouldn't have to do any clock switching at all...?

    I guess the only bit that's left for me to understand is whether XDC applies any clock configuration that might explain the difference I'm seeing in the low speed clock source between a bare metal project (RCOSC_LF) and an RTOS project when RTOS is not yet started (RCOSC_HF) when all the preceding code is identical.  Any thoughts?

    Thanks,

    Hester

  • 0 in reply to Hester Corne
    TI__Guru 58425 points

    Do you compare before or after "Board_init()" in the RTOS case? In most of our examples (if not every), the Power driver is initialized first thing in main() as part of "Board_init/initGeneral", this is also responsible for the initial clock switching based on the CCFG settings.

    In your case, you would likely still need to switch the LF source initially to go into standby as it should be "derived" when coming from a cold boot.

  • 0 in reply to IUsedToBeARealPerson (M-W)
    Intellectual 790 points

    Hi M-W,

    I can't see a Board_init() function anywhere in my application, so Power_init does not appear to be called.  However, this set me on a new trail and I realised the one other difference about this project is that I'm using the Startup.resetFxn feature from XDC.  I'm actually calling my standby code from within here and have now found that by the time I call the OSCClockSourceGet function the clock settings don't seem to be applied yet.  If I insert a CPUdelay of 5100 cycles before this function call I see the low speed clock source coming back as expected.  Anything less than that and it comes back as RCOSC_HF.

    This creates more issues for me to resolve but I think answers the question of why my clock source is unexpected.

    Thanks for your help :)

    Hester