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.

LAUNCHXL-CC26X2R1: Sleep functionality in BIM

Part Number: LAUNCHXL-CC26X2R1

Hi,

I am working on the TI SDK v5.10 and using the BIM project.

My device is power constraint device, so I need to put it in sleep/stand by mode after some operation(verifying the Firmware Image) in BIM.

Is there any API available for the BIM, which puts the system in sleep mode, so that it can recharge and wake-up when recharge is completed (GPIO interrupt)?

Let me know if I need to elaborate anything.

Regards,
Shiv

  • Hi Shiv,

    The BIM project can access the Driverlib so I imagine you would be able to reference setLowPowerMode from bim_util.c but replace IntMasterDisable with IOCIntRegister (IntRegister & IntEnable) using INT_AON_GPIO_EDGE after having enabled the GPIO as an interruptable input with IOCPortConfigureSet/IOCIOIntSet.

    Regards,
    Ryan

  • Hi Ryan,

    Sorry for the delay.

    Thanks, with the given instruction I was able to put the BIM is deep sleep mode and was able to wake up with the help of GPIO interrupt. But I am facing issue when I am again trying to wakeup the BIM with help of GPIO interrupt i.e. I am doing following steps in main():

    1. Performing some external flash related function which consume significant amount of energy
    2. Calling setLowPowerMode (modified as per your instruction) so that device can again recharge
    3. Generating GPIO interrupt when device is fully charge. Clear the interrupt and set some flag in handler
    4. Repeating 1 to 3 until required data read from external flash 

    So, for the first time, step 1 to 3 work as expected but for the 2nd time, device stuck at step 2 even though I am generating GPIO interrupt. Is any other function call needed for my requirement? Or something I am doing wrong?

    Regards,
    Shiv

  • Can you provide more details from your debug investigation?  Also, are you clearing the interrupt source (IOCIOIntClear)?  If it works the first time but fails afterwards this would imply that something has not been properly reset for repeating the action.  Please monitor your registers closely to make sure they are the expected values before you return to the LPM.

    Regards,
    Ryan

  • Hi Ryan,

    I was checking the registers value, it was same as before I am going to the LPM(as shown below).

    Today I had investigate more into it. For having clarity, I have used out of box BIM example code. I have commented all the code in the main and replace it with following:

        static uint8_t utpHandlerCount_main = 0;
        powerUpGpio();
        blinkLed(RED_LED, 5, 100);
    
        IOCPortConfigureSet(IOID_18, IOC_PORT_GPIO, IOC_INT_ENABLE | IOC_BOTH_EDGES | IOC_INPUT_ENABLE );
        setLowPowerMode();
        while(utpHandlerCount_main < 10)
        {
            utpHandlerCount_main++;
            setLowPowerMode();
        }
        blinkLed(RED_LED, 5, 100);

    and for the setLowPowerMode(), I have made the changes as suggested by you:

    void setLowPowerMode()
    {
        utpHandlerCount++;
        // Enable the GPIO Interrupt
        IOCIntRegister(utpHandler);
        
        /*  - Freeze the IOs on the boundary between MCU and AON
         *  - Make sure AON writes take effect
         *  - Request power off of every PD in the MCU voltage domain
         *  - Ensure that no clocks are forced on in Crypto, DMA and I2S
         *  - Gate running deep sleep clocks for Crypto, DMA and I2S
         *  - Load the new clock settings
         *  - Configure the VIMS power domain mode to power up flash
         *    again after coming out of standby.
         *  - Request uLDO during standby
         *  - Use recharge comparator
         *  - Ensure all writes have taken effect
         *  - Ensure UDMA, Crypto and I2C clocks are turned off
         *  - Ensure all non-CPU power domains are turned off
         *  - Turn off cache retention if requested
         *  - Invoke deep sleep to go to standby
         */
        SysCtrlStandby(false,
                       VIMS_ON_CPU_ON_MODE,
                       SYSCTRL_PREFERRED_RECHARGE_MODE);
    }

    and In the handler, I am perform following:

    static uint8_t utpHandlerCount = 0;
    
    void utpHandler(void)
    {
    //    IntPendClear(INT_AON_GPIO_EDGE);
    //    IntDisable(INT_AON_GPIO_EDGE);
    
        IOCIntClear(IOID_18);
        IntDisable(INT_AON_GPIO_EDGE);
        if(utpHandlerCount > 0)
        {
            utpHandlerCount++;
        }
        blinkLed(RED_LED, 5, 100);
        
        IntEnable(INT_AON_GPIO_EDGE);
    }

    After investigating more and debugging it, It seems IOCIOIntClear() wasn't able to clear the previous interrupt received from the GPIO as I am stuck in the handler only. I tried to read the GPIO_O_EVFLAGS31_0 register but wasn't able to do so, and also tried to use the IOCIntStatus(IOID_18), but it was generating fault ISR().

    And for my previous observation, where I was able to again go to LPM (i.e. comes out of handler), there I was using IntDisable(). So, I think it was disabling the interrupt in the handler and when setLowPowerMode() was called, it agian enable the interrupt and go to LPM.

    Is something I am doing wrong? or any other function need to be called after wakeup from LPM that I am missing (I look into technical reference of CC26x2 for standby but I wasn't able to find any specific thing which mention operation to do after wakeup from standby mode)? As IOCFG for GPIO seems always correct before going to sleep.

    Regards,
    Shiv

  • Thanks for providing details as to your setup, I was able to recreate your issue as such.  Please use PRCMPeripheralDeepSleepEnable(PRCM_PERIPH_GPIO); during initialization and PRCMDeepSleep(); instead of SysCtrlStandby, this should improve the behavior and allow you to further develop your solution

    Regards,
    Ryan

  • Thanks Ryan, after making changes as per suggestion BIM was working as expected.

    But I have few question regarding it. As per technical reference of cc26x2, before going to standby mode, we have to perform certain operation(as shown below) and as per my understanding SysCtrlStandby() was performing those.

    i.e. as per your suggestion we directly going setting the SLEEPDEEP bit without performing any of the above operation. Is there going to be any issue related to System state retention or anything like that? As of now, I have only tested with example code i.e. I haven't perform any external flash as well as internal flash operation after wakeup from deep sleep. I just want to be sure that I wouldn't be getting into any issue by performing other operation (i.e. flash read/write related operation) after wakeup.

    Regards,
    Shiv

  • You are correct, what we've determined is that it is not your pin configuration but rather the way you are entering/recovering from the standby state that is causing the behavior.  The original BIM code simply invokes a standby state from which it does not expect to return, since this is not the case for your application there are additional steps which need to be achieved.  You can refer to the PowerCC26X2.c Power_sleep function for a reference as to how the Power.h TI Driver accomplishes this functionality.  The issue is that the reserved BIM flash space is too small to use TI Drivers and no other Driver library sleep example code is provided.

    Regards,
    Ryan

  • Thanks Ryan for sleep function reference. I will look into it.

    As of now, I will implement this functionality in my Customize BIM code as per my requirement. If something comes up, I will let you know.

    Regards,
    Shiv