• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 51 subscribers
  • Views 2042 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.

Original question:

RTOS/CC2640: Wakeup from shutdown with pin inconsistent

RTOS/CC2640: Wakeup from shutdown with pin inconsistent

Paul Seifert
Prodigy 170 points
Part Number: CC2640

Tool/software: TI-RTOS

Hello,

I am using the following in my software development.

BLE Stack 2.2.1

TI-RTOS for CC13XX and CC26XX 2.20.1.08

CCS 6.2.0.00050

XDCtools 3.32.0.06

Compiler TI v5.2.6

This is a follow up to an original thread I posted about inconsistent wake up from shutdown behavior I was seeing from my custom circuit board that uses the CC2640 microcontroller. I got new circuit boards that addressed the hardware items that were identified in the original thread using the "CC26xx BLE HW Troubleshooting & Bring Up" article. Unfortunately, the hardware changes did not fix the issue and I am seeing the same behavior in my updated boards.

The issue is as follows (slightly abbreviated from previous thread and modified for the slight change in behavior in the new boards):

I have an application where I want to be able to send the CC2640 into shutdown mode and then wake it up with an wake up pin. The software wakes up from a pin interrupt, uses the PIN, I2C, SPI, PWM, Timer, BLE, and UART peripherals to perform various tasks, then goes back into shutdown mode waiting for a new wakeup pin event.

My issue is that the wake up pin functionality seems to stop working on my circuit boards after unrelated software tweaks. With my latest custom software package (based on the simple peripheral example project), I get the following behavior:

- Boards wake up correctly when power is supplied to the board. After going to shutdown mode, the boards are pulling approximately 250 uA (normal shutdown current is 16-20 uA with all board peripherals) and are unable to wake up with a pin interrupt. Pulling the reset pin or removing the power and plugging it back it gets the board to turn on normally, but gets stuck once the board is in shutdown mode again.

Reverting to an earlier software version can get the boards to wake up with pin interrupts without issues. When I take the latest software package and start removing added lines of code (unrelated to shutdown/wakeup functionality), I can get the boards to work normally, but it is not consistent. In addition, certain hex files can get the boards to work normally without issue, then reprogramming the same board with the same hex files cause to to exhibit the bad behavior again. One thing of note is that once I get a board working normally or "bad", it never reverts to the other behavior even after multiple power and reset cycles. Only reprogramming the board can get it to switch between "good" and "bad" behavior.

Regardless of the wakeup issue, all of the boards seem to properly go through the first wake up sequence when power is initially supplied to the board. I can confirm that running the wakeup from shutdown pin example RTOS project gets all boards to work without issue. I can also confirm that running my latest software version on the CC2650 launchpad shows normal behavior.

Because this does not seem to be caused by any specific line of code, I thought this could be some sort of memory issue. But I seem to have plenty of flash, ram, and stack space.

I also checked the IO pin registers to confirm that by the time the Power_Shutdown() function is called, the WU bits are set up properly for a wakeup from shutdown event.

I am looking for advise on where to look next. I don't believe this is a hardware issue on my custom board as I can get all the boards to wake up from shutdown using a pin interrupt in stripped down versions of the custom software (only wakes up, lights up LED for 1 second, then shuts down) and the RTOS example project. But I am struggling to isolate what is causing this issue. I know that since I am working with both custom hardware and software, it may be difficult to give specific advice. Regardless, any help would be appreciated.

Thanks,

Paul

  • 0
    TI__Guru 56590 points
    Hello Paul,
    That sounds very odd.
    What happens if you disable one of the serial interface one by one?
    Can you try to measure the current on the serial IO pins while the device is in the 250 uA shutdown current mode?

    I would advice you to try to upgrade to the latest BLE-STACK-2-2-2, although I don't suspect this issue is related to the fixes there.
  • 0 in reply to Eirik V
    Prodigy 170 points
    I tried to disabled / enable things one by one as you suggested. Here is the results of that test.

    1) Did not initialize SPI, UART peripherals, Limited i2c communication to 1 peripheral. Simplified code to wake up, pwm led, set up 1 peripheral, turn off led, shutdown device (overall, takes ~20ms from wakeup back to shutdown). Wakes up properly with wakeup pins. Current draw ~500uA, but this is expected as certain peripherals are no longer in low power states as I do not talk to them.
    2) added other i2c peripherals back in. Kept simplified code structure. Wakes up properly with wakeup pins.
    3) Added UART initialization back in. Added single UART transmit to simplified code structure. Wakes up properly with wakeup pins.
    4) Added SPI initialization back in. All board peripherals are now talked to during the 20ms before shutdown. Current consumption down to <20uA. Wakes up properly with wakeup pins. At this point, the code exactly matches the normal software for what the software does when the device has a power reset or the reset pin pulled. I have it treating all pin wakeup events like those events.
    5) Enabled some additional functions for the normal start up procedure upon receiving a pin wake up event (goes through different LED PWMs, Reads data from some peripherals, does some calculations before shutdown). Current consumption at 250 uA at shutdown. Does not wake up with wakeup pins.
    6) Bring it back to step 4 configuration. Current consumption at 250 uA at shutdown. Does not wake up with wakeup pins.
    7) Bring it back to step 3 configuration. Current consumption at 750 uA (spi peripherals not configured) at shutdown. Does not wakeup with wakeup pins.
    8) Bring it back to step 2 configuration. Current consumption at 750 uA at shutdown. Does not wakeup with wakeup pins
    9) Bring it back to step 1 configuration. Current consumption at 750 uA at shutdown. Does not wakeup with wakeup pins

    This is pretty typical of the issues I have been seeing, where I start by pulling back on a bunch of functionality and get it to wake up properly. I Slowly add features back in and at some point, lose the wakeup functionality. Try to revert back to an early working software version that previously worked, and it is still unable to wake up properly.

    Note that in all 9 steps, the device properly pwmed the LED when power was supplied to the board or when the reset pin was pulled low.

    In this test, I was programming with the SmartRF06 Evaluation Board and the SmartRF Flash Programmer 2 software.



    I will get back to you on your serial IO current measurement suggestion and the BLE-STACK-2-2-2 suggestion.

    Thanks,

    Paul
  • 0 in reply to Paul Seifert
    Prodigy 170 points
    Hello,

    I was able to figure out the issue and resolve it. It was a 2-fold problem. First, one of my peripherals was not properly configuring its interrupt line during initialization, causing the peripheral to always pull the interrupt line active low. I had the microcontroller configured with an internal pullup on that interrupt line and the combination of these two situations caused a constant ~250 uA current draw across the interrupt line, which accounts for the additional current I was measuring when the board was having an issue.

    Second, I had several pins set up to wake up the microcontroller, including the interrupt line that was always pulled low (set up as a negative edge detect). I discovered that if a pin is set up for a wakeup event as positive/negative edge detect and that pin is already high/ low when the device is shut off, it blocks the microcontroller from recognizing any generated interrupts on any other wakeup pins as long as it stays high/low.

    Therefore, the interrupt line that was always pulled low was preventing the interrupts from other peripherals from waking up the device from shutdown, which is why I could not get the microcontroller to wake up.

    I am curious if this interrupt behavior in the wakeup from shutdown feature of the microcontroller is a known thing or not, but otherwise I was able to fix the issue and now everything is working as expected.

    Thanks for the help!

    Paul
  • 0 in reply to Paul Seifert
    TI__Guru 56590 points
    Happy to hear you did some proper debug and solved the problem.
    I am not sure yet if this can be expected.
    Did you use the PIN driver or the GPIO driver to set up the interrupt on pins?
  • 0 in reply to Eirik V
    Prodigy 170 points

    Eirik,

    I used the PINCC26XX driver. Specifically,

    I use the Pin_Config function to create my table of wakeup interrupts and the PINCC26XX_setWakeup function to configure the IO for wakeup from shutdown

    For initializing pins on wakeup (in main.c), I used the PIN_init and the PIN_Config function. Both the general GPIO PIN_Config table used in PIN_init and the wakeup PIN_Config table used before shutdown only use the PINCC26XX Flags.

    Thanks.

  • 0 in reply to Paul Seifert
    TI__Guru 56590 points
    Hello Paul,
    I was able to reproduce this behavior on tirtos_cc13xx_cc26xx_2_21_01_08 on a CC2650LP. I will check whether this is expected or not.
  • 0 in reply to Paul Seifert
    TI__Guru 56590 points
    Hello Paul,
    This is expected behavior in HW. But this is not documented well enough in our online collateral. I will add a ticket to update our documentation.

    The IO pads are level sensitive when configured for wake up from shutdown (WU_CFG in IOCFGx ). An internal signal is generated from the pad when the input level match the set level (WU_CFG - 10: LOW, - 11: HIGH). All these signals from the IO pads are internally OR'ed together to form a single signal routed to an internal edge trigger block. When one of the input signals remain active there will be no edge on the internal edge detect block until the active input is released. If then one of the several input configured for wake up from shutdown is active before they are configured and the device enter shutdown there will be no internal edge to wake up the device.

    One workaround can be to check the IO inputs before you enter shutdown and abort.