• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 373 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

RTOS/CC2640R2F: Pin Wake Strange Behavior Multiple Sources

Joshua Hess
Intellectual 490 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640, UNIFLASH

Tool/software: TI-RTOS

Hello,

I am using the PIN driver to wake the mcu from sleep state if one of two sources go low. There are two strange issues I have found. 

The first issue is if one of the two sources is already low when the other is pulled low to wake. It works as expected if one of the two sources is pulled low to wake while the other is high, but if one of them is kept low and the other is pulled low to wake, it does not wake. I am not sure why this is and can't find any information on this.

The second issue is the pin wake does not work at all right after debugging. It seems that a chip reset is necessary before the pin wake functionality works. This is not a big deal, but I would like to understand why this behaves in this manner. 

Below is my code for configuring the pin wake:

Wakeup Table:

PIN_Config ButtonTableWakeUp[] = {
    fButtonR    | PIN_INPUT_EN | PINCC26XX_WAKEUP_NEGEDGE,
    chargeState | PIN_INPUT_EN | PINCC26XX_WAKEUP_NEGEDGE,
    PIN_TERMINATE                                 /* Terminate list */
};

Set wakeup:

PINCC26XX_setWakeup(ButtonTableWakeUp);

Pin Driver Config:

/*
 *  =============================== PIN ===============================
 */
#include <ti/drivers/PIN.h>
#include <ti/drivers/pin/PINCC26XX.h>

const PIN_Config BoardGpioInitTable[] = {

    PIN_TERMINATE
};

const PINCC26XX_HWAttrs PINCC26XX_hwAttrs = {
    .intPriority = ~0,
    .swiPriority = 0
};

Any help on these issues is greatly appreciated. Thanks!

  • 0
    TI__Guru 58425 points

    Hi Joshua,

    This is the expected behavior, simply put you can consider the wake-up signals to be "ORed" together internally and a transition on this combined signal is what causes the wake-up. In case a wake-up from another pin is already "active" (for example the pin is kept low), a transition on the second pin will not cause the ORed signal to change as the already asserted IO is blocking it. 

    When it comes to wake-up not working straight from debugging, could you elaborate on this. Is it wake up from shutdown or standby? Could you share a full code snippet on how you setup the PIN driver in you case?

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

    Hello,

    Thank you for your reply. Regarding the wake-up signals being ORed together, is there no way to change this behavior to ANDed? 

    The debugging issue only occurs directly after flashing the chip and starting a debug session. It is waking from a shutdown state as defined by this function call: Power_shutdown(0, 0); 

    I am not using the PIN driver for any other functions other than this wake functionality, I use the GPIO driver for everything else. The Pin driver config looks as follows:

    /*
 *  =============================== PIN ===============================
 */
#include <ti/drivers/PIN.h>
#include <ti/drivers/pin/PINCC26XX.h>

const PIN_Config BoardGpioInitTable[] = {

    PIN_TERMINATE
};

const PINCC26XX_HWAttrs PINCC26XX_hwAttrs = {
    .intPriority = ~0,
    .swiPriority = 0
};

    I saw it was recommended to use the GPIO driver over the PIN for the CC2640 chips and that the GPIO driver was basically a wrapper for the PIN driver. Is the pin wakeup functionality separate from the normal PIN driver?

  • 0 in reply to Joshua Hess
    TI__Guru 58425 points

    Hi Joshua,

    Unless you require to migrate the code to a CC32XX or MSP432 platform I recommend you stick with the PIN driver, there is no difference in wakeup functionality as the GPIO driver in this case is simply a wrapper.

    There is no way to change this behavior, it is the design of the hardware. 

    As for the wakeup from debug issue, this would be expected as waking from shutdown is basically a device reboot. When the debugger is attached to the device, the ICEpick will halt the device in boot during a reset. When running without the debugger, this should not be an issue for you.

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

    Thank you for the information. I will implement a software workaround for the wakeup behavior now that I know it is the design of the hardware. I have found that when using the UniFlash utility, a chip reboot can be selected after flashing which mitigates the booting issue when loading production images.

    Thanks for your help again!