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.

CC3220MODA: GPIO retention during LPDS mode

Part Number: CC3220MODA
Other Parts Discussed in Thread: SYSCONFIG, CC3220SF

Hello, 

I am attempting to park a pin high during LPDS mode, but it is not working. I have filled in the park structure for that pin as follows:

PowerCC32XX_ParkInfo parkInfo[] = {

     ...

    {PowerCC32XX_PIN18, PowerCC32XX_DRIVE_HIGH},         /* GPIO28              */

     ...

};

The power configuration is as follows:

const PowerCC32XX_ConfigV1 PowerCC32XX_config = {
    .policyInitFxn = &PowerCC32XX_initPolicy,
    .policyFxn = &PowerCC32XX_sleepPolicy,
    .enterLPDSHookFxn = NULL,
    .resumeLPDSHookFxn = NULL,
    .enablePolicy = false,
    .enableGPIOWakeupLPDS = true,
    .enableGPIOWakeupShutdown = true,
    .enableNetworkWakeupLPDS = true,
    .wakeupGPIOSourceLPDS = PRCM_LPDS_GPIO24,
    .wakeupGPIOTypeLPDS = PRCM_LPDS_RISE_EDGE,
    .wakeupGPIOFxnLPDS = NULL,
    .wakeupGPIOFxnLPDSArg = 0,
    .wakeupGPIOSourceShutdown = PRCM_HIB_GPIO13,
    .wakeupGPIOTypeShutdown = PRCM_HIB_RISE_EDGE,
    .ramRetentionMaskLPDS = PRCM_SRAM_COL_1 | PRCM_SRAM_COL_2 |
        PRCM_SRAM_COL_3 | PRCM_SRAM_COL_4,
    .keepDebugActiveDuringLPDS = false,
    .ioRetentionShutdown = PRCM_IO_RET_GRP_1 | PRCM_IO_RET_GRP_0,
    .pinParkDefs = parkInfo,
    .numPins = sizeof(parkInfo) / sizeof(PowerCC32XX_ParkInfo)
};

We are going to LPDS, but I can see that GPIO 28 is NOT staying high. 

I'm able to step into the parkPins() function, but the debugger disconnects before I can verify that we're actually getting to the call to MAP_PinLockLevelSet that sets it high. 

Are there any secret tricks besides setting the above structures that I could be missing? 

Thanks,

Katie

  • Hi Katie,

    Are you using SysConfig for your driver configuration?

    I will have to check the drive strength that is expected in LPDS. Please allow me a few days to verify this behavior.

    Best regards,

    Sarah

  • No, we're not using SysConfig. 

    Thanks,

    Katie

  • Hi Katie,

    What are you trying to drive? What is the resistance?

    The typical drive strength GPIO levels are 2-6 mA. When the MCU is in LPDS, it's consuming uA. It wouldn't have enough current drive an LED, for example, even if the voltage is a logic high or low. The pin parking mechanism is primarily to reduce current leakage for low power applications.

    Best regards,

    Sarah

  • GPIO28 is connected to EN of this LDO which draws 10nA: https://www.ti.com/lit/ds/symlink/tlv705.pdf?HQS=TI-null-null-digikeymode-df-pf-null-wwe&ts=1600904541651 

    We're at 3.3V and there is a 100k pull down. That puts us at 33uA + 10nA.  Too high for LPDS?

    Thanks,

    Katie

  • Ok, I am now able to keep the GPIO high during LPDS, but now it will no longer go LOW. If I disable the function to enter LPDS, GPIOs work normally. But when LPDS is enabled, the GPIOs just stay in one state. I am wondering if I need to UNPark the pins, but I don't see a way to do that. Please advise 

    Thanks,

    Katie

  •   Some changes to my setup:

    • 100K pulldown resistor is removed, so current shouldn't be an issue.
    • I've configured the GPIO to be pull up, and can control the logic out up until the first time I go to LPDS:
      • HWREG(GPIO28_CONFIGURATION_ADDRESS) = (DRIVE_STRENGTH_2_MA | PULLUP_ENABLE);
    • Park setting:    {PowerCC32XX_PIN18, PowerCC32XX_DRIVE_HIGH},         /* GPIO28              */
    • On wakeup from LPDS, I reinitialize the GPIO registers to set direction, drive strength, and pullup enable, but NOT actual logic output because I want that to stay the same as it was before going to sleep. 

    What I'm looking for is the pad to stay at the same logic level it happened to be in when I call the LPDS function, to stay at that value on wakeup until I have a need to change it (i.e. normal GPIO control). For this particular pin, sometimes I will want it to be high during LPDS, and other times I will want it to be low during LPDS.

    • Is the intent of the park value to actually set the logic level of the pad during LPDS?
  • Part Number: CC3220MODA

    I am looking for clarification on parking pins during LPDS mode. In our application we don't always want the pins in the same logical state every time we go to LPDS.  Is the purpose of parking to actually set the state of the line during sleep? Or can you just set it normally and have it maintain whatever state it was in. If so, what is the correct park pin setting for that? 

    The other portion of the question is what is necessary to getting back control of the pins after coming out of LPDS. I'm having some issues controlling the GPIOs after exiting LPDS. 

    On exit of sleep, I'm re-configuring the following settings on the GPIOs:

    • direction
    • drive strength
    • pull up/down
    • interrupts (if applicable)

    Is there something else I should be doing? 

    Thanks,

    Katie

  • Hi Katie,

    Are you using the TI Driver power policy (Power_enablePolicy) in the SDK? What SDK version?

    By default, GPIOs should park in the same state as they were when entering LPDS. If you statically park the pins, you will be overwriting this behavior when entering LPDS. When exiting LPDS, the power policy will reconfigure the pins to their previous state. You can see the source for Power_sleep() in source/ti/drivers/power/PowerCC32XX.c and PowerCC32XX_sleepPolicy() in kernel/<rtos>/packages/ti/dpl/PowerCC32XX_tirtos.c.

    The intent of pin parking is to reduce current leakage to limit battery consumption. It is not meant to control external components in LPDS.

    Best regards,

    Sarah

  • In CC3220SF_LAUNCHXL.c I've got the PowerCC32XX_ParkInfo parkInfo[] structure, largely based on one of the example projects (likely network_processor one). It sets each pin to one of the following:

    /*! @brief Enumeration of states a pin can be parked in */
    typedef enum {
    /*! No pull resistor, leave pin in a HIZ state */
    PowerCC32XX_NO_PULL_HIZ = PIN_TYPE_STD,
    /*! Pull-up resistor for standard pin type */
    PowerCC32XX_WEAK_PULL_UP_STD = PIN_TYPE_STD_PU,
    /*! Pull-down resistor for standard pin type */
    PowerCC32XX_WEAK_PULL_DOWN_STD = PIN_TYPE_STD_PD,
    /*! Pull-up resistor for open drain pin type */
    PowerCC32XX_WEAK_PULL_UP_OPENDRAIN = PIN_TYPE_OD_PU,
    /*! Pull-down resistor for open drain pin type */
    PowerCC32XX_WEAK_PULL_DOWN_OPENDRAIN = PIN_TYPE_OD_PD,
    /*! Drive pin to a low logic state */
    PowerCC32XX_DRIVE_LOW,
    /*! Drive pin to a high logic state */
    PowerCC32XX_DRIVE_HIGH,
    /*! Take no action; do not park the pin */
    PowerCC32XX_DONT_PARK
    } PowerCC32XX_ParkState;

    Which is the default?

    Thanks,

    Katie

  • forgot to mention: simplelink_cc32xx_sdk_2_40_02_00

  • Hi Katie,

    The GPIO driver will assign an output pin to park in DRIVE_HIGH or DRIVE_LOW, depending on its state when entering LPDS. If GPIOCC32XX_USE_STATIC is set for that pin, the pin will park according to the parkInfo table instead.

    Best regards,

    Sarah

  • We're not using the TI GPIO code. However, I do see the parkInfo stuff being used in the PowerCC32XX codein Power_sleep(), which we ARE using. Tracing that code, it looks like it just configures the GPIO like normal but to the value set in pinParkDefs. I think I was thrown off by the "park", thinking it was doing something special to the GPIO.

    Anyway, reducing current required (as you suggested in the other thread) by changing the hardware pull down and making sure the GPIO registers are re-initialized after LPDS mode (except for the actual pin state) seem to have been the key things to get it working. 

    Thanks,

    Katie

  • Removing the hardware pull down to reduce current draw while in LPDS and making sure the GPIO registers are re-initialized after LPDS mode (except for the actual pin state) seem to have been the keys to get it working. 

    Thanks,

    Katie