CC2652RB: Configure LDO vs. DCDC at Runtime

Hello Tyler!

The general consensus is that the CCFG should not be written to during runtime, as it would require an erase/write flash procedure and a failed attempt could brick the device.  Here are E2E threads on the topic:

https://e2e.ti.com/f/1/t/1197426 
https://e2e.ti.com/f/1/t/919521 
https://e2e.ti.com/f/1/t/647417 
https://e2e.ti.com/f/1/t/998671 

I will have a SimpleLink HW expert address your last two questions.

Regards,
Ryan

Hey Ryan!

I don't know if I improperly phrased my question, but we definitely DON'T want to resort to updating the CCFG at runtime; that sounds scary.

We're looking for a solution where we can bypass the CCFG settings entirely, ideally through some sort of driver-based functions. Is this possible? Or are the power drivers all hard-coded into ROM and unchangeable?

-Tyler

We're all clear on there not being a way to modify the CCFG at runtime.  But our end goal isn't "modify CCFG" so much as it is "disable DC/DC and use LDO instead."  You may be saying that the only way to do that IS via the CCFG setting, but we'd like an explicit confirmation of such if that's the case.  Because we don't care if we can't change the CCFG if there's still another API, or power function we can modify, or register we can write that will simply switch operation from the DC/DC to the LDO.  We have devices in the field that we can OTA update if there's a way to modify whatever function would be reading from the CCFG that we can't change.

In other words, is something like this still possible for the CC2652R.

To add to Chris's response - we essentially want to know what code is USING the defines in the CCFG that are set (that we DON'T want to change).

The next step from there is to find out if that code can be modified at all, and if so, how we can do that to ensure our idle task and power profile within the RTOS is such that we're able to choose our regulated voltage supply source.

Ah, TIL and thanks for bearing with me!   So the APIs mentioned in the other E2E thread are still relevant for CC26X2 devices.

SysCtrl_DCDC_VoltageConditionalControl 
PowerCtrlSourceSet

<CC26X2_sdk_directory>\kernel\tirtos7\packages\ti\dpl\PowerCC26X2_tirtos.c does no use SysCtrl_DCDC_VoltageConditionalControl directly as with <CC26X0_sdk_directory>\kernel\tirtos\packages\ti\dpl\PowerCC26XX_tirtos.c inside the PowerCC26XX_standbyPolicy, however it does use PowerCC26X2_sysCtrlUpdateVoltageRegulator which just maps to SysCtrl_DCDC_VoltageConditionalControl(); 

So, assuming that the process is the same as before then you would copy PowerCC26X2_tirtos.c directly into your project workspace and comment out PowerCC26X2_sysCtrlUpdateVoltageRegulator.  Then you use the PowerCtrlSourceSet function directly inside your application.  You can use PowerCtrlSourceGet afterwards to confirm that the change took effect after waking up from a low power mode in accordance with the Driverlib notes

The system will never allow a switch to the PWRCTRL_PWRSRC_ULDO when in active mode. This is only allowed when the system is in lower power mode where no code is executing and no peripherals are active. Assuming that there is an external capacitor available for the PWRCTRL_PWRSRC_DCDC the system can dynamically switch back and forth between the two when in active mode.The system will automatically switch to the GLDO / DCDC when waking up from a low power mode.

This change is based on the AON_PMCTL:PWRCTL register which you can monitor inside a debug session or report out using a communication peripheral, LED, etc.  Sorry again for the earlier confusion and please let me know if the suggested method works for your system.

Regards,
Ryan

Ryan - thanks for the summary and details. Chris and I will be looking into this over the coming days and will reach out if we have any additional questions!