• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 52 subscribers
  • Views 525 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.

CC2652P7: Using 48MHz crystal all the time if GPIO is set

Matt Gaidica1
Expert 1540 points

Part Number: CC2652P7
Other Parts Discussed in Thread: SYSCONFIG

I'm observing some time drift (3 seconds per day in one case) in modules that spend a lot of time in low-power mode. I only have the 48MHz crystal mounted, so I assume this is from reliance on the RCOSC. I have a GPIO that is pulled to ground when the module is on a "base station" where power is abundant, therefore, I would like it to startup and rely on the 48MHz crystal for all timekeeping. I originally thought that I could Sysconfig the LF Clock to derive from HF, the at init do:

if (GPIO_read(BASE_GPIO) != 0)
    {
        OSCClockSourceSet(OSC_SRC_CLK_LF, OSC_RCOSC_LF);
        while (OSCClockSourceGet(OSC_SRC_CLK_LF) != OSC_RCOSC_LF)
            ;
    }

However, this doesn't achieve low-power. It idles around 1mA, whereas if Sysconfig LF is RCOSC, it is down ~90uA. Maybe there is another route to go. The alternative is to init with RSOSC, then change to sourcing the XOSC_HF (it appears this is what happens when you select "Derived from HF XOSC in Sysconfig), but when I try to connect over BLE it times out:

if (GPIO_read(BASE_GPIO) == 0)
    {
        OSCClockSourceSet(OSC_SRC_CLK_LF, OSC_XOSC_HF);
        while (OSCClockSourceGet(OSC_SRC_CLK_LF) != OSC_XOSC_HF)
            ;
    }

I see that the Sysconfig output is only used in building the .ccfg and loaded at boot, so I'm not sure this is the correct route.

  • 0
    Expert 1540 points

    I guess another option is to disallow shutdown/standby/idle?

    if (GPIO_read(BASE_GPIO) == 0)
    {
        Power_setConstraint(PowerCC26XX_SD_DISALLOW);
        Power_setConstraint(PowerCC26XX_SB_DISALLOW);
        Power_setConstraint(PowerCC26XX_IDLE_PD_DISALLOW);
    }

    This results in 2.5mA current all the time, so I'm assuming that is going to use the crystal. To clarify, I am keeping time using a clock module interrupt that increments a uint32.

  • +1 in reply to Matt Gaidica1
    TI__Guru** 101490 points

    Hi Matt,

    Both options should get you to keep the 48MHz crystal active.

    I would recommend the second approach you have shared (consisting in leveraging Power_setConstraint) as it is less likely to interfere with other operations (especially radio operations).

    Best regards,

  • 0 in reply to Clément
    Expert 1540 points

    I didn't have great results with that option. I'm curious why the solution below specifically causes issues during a BLE connection? If I change this from RCOSC to HF_XOSC at startup for "base stations", it appears everything works except forming a connection (it just drops after a few seconds of being connected).

    if (isBase) // back to HF
    {
        OSCClockLossEventDisable();
        OSCClockSourceSet(OSC_SRC_CLK_LF, OSC_XOSC_HF);
        while (OSCClockSourceGet(OSC_SRC_CLK_LF) != OSC_XOSC_HF)
            ;
        OSCClockLossEventEnable();
    }

    But if I change the clock source back to RCOSC (it's default) at GAP_LINK_ESTABLISHED_EVENT, the connection forms.

  • 0 in reply to Matt Gaidica1
    Expert 1540 points

    This strategy is no good. Something about it doesn't replicate the accuracy of simply selecting the "Derived by XOSC_HF" option in Sysconfig. Seeking details on how to do that after boot...