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/CC2640: Wakeup from shutdown with pin inconsistent

Part Number: CC2640
Other Parts Discussed in Thread: CC2650

Tool/software: TI-RTOS

Hi,

My setup:

CC2640 Chips, Revision 2.3

BLE Stack 2.2.1

TI-RTOS 2.20.01.08

CCS Studio 6.2.0.00050

SmartRF Flash Programmer 2 version 1.7.5

Programming with XDS100 v3 via a SmartRF06 Evaluation Board

Custom Software built upon the simple peripheral example project

Custom 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 is set up where upon first supplying power, it uses the PIN, I2C and UART peripherals for a short duration, then immediately goes to shutdown mode to wait for a new wakeup event via a pin interrupt. When a wakeup interrupt is received, the device wakes up, 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 certain circuit boards after unrelated software tweaks. With my latest custom software package, I can get the following behaviors:

- Certain boards work normally and always work every time the software is programmed to the board.

- Other boards will either never wake up from the pin interrupt, or will only wakeup up from a pin interrupt the first time after programming and then will not work again (until software is reprogrammed). Removing power and pulling the reset pin low does not fix the issue. The same circuit board can show both of the "bad" behaviors over programming it multiple times.

For the boards that are having issues, reverting to an earlier software version can get them to exhibit normal behavior without issues. When I take the latest software package and start removing added lines of code (unrelated to shutdown/wakeup functionality), I can get some of the "bad" boards to work like normal, but it does not fix all of the "bad" boards. Removing different lines of code can get different boards to start/stop working. In addition, certain hex files can cause a "bad" board 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. It might also be worth noting that while I have some boards that are bad but I can tweak the software to make good, I have certain boards that have never had an issue.

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 properly. 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. (still working after multiple resets and multiple power cycles (power cycles only work when programming jumpers removed))

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, as shown in the screenshots below.

In case it is relevant, the lines of code I am modifying to get some boards to change behaviors are related to I2C communication with a peripheral, though I have other sections of code that use I2C without causing an issue.

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. Below is a screenshot of the shutdown code (this has not changed between the software versions that worked and the latest which is not working.)

I guess 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 piece of the software 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

  • Looks like pictures did not show up, so here they are...

  • Hello Paul,

    I don't suspect a memory issue either. Have you gone through the "CC26xx BLE HW Troubleshooting & Bring Up" article on the BLE wiki and confirmed that your board's layout follows our reference design, including correctly sized and placed passive components? We have seen incorrectly sized components and/or poor power/clock/ground layout lead to inconsistent behaviour.

    Also, when the bad boards are misbehaving, taking a current measurement would be helpful in identifying what state the MCU is in at the time of failure.

    Hopefully this is enough to start investigating further.

    Best wishes
  • Hi JXS,

    I took current measurements of some of the boards in shutdown mode and found the following:

    - If current consumption on board (micro + peripherals) < 10 uA (peripherals are a large majority of the current consumption), board wakes up properly from shutdown mode with pin interrupt

    - boards that were not able to wake up with pin showed a shutdown mode current consumption of 180 uA.

    -All tested boards had < 10 uA after the first power up after programming the micro. Bad boards switch to 180 uA after intitial wake ups and remained that way even after multiple power cycles.

    -I had one board show a current draw of 510 uA during shutdown mode after 1 particular power cycle event. Only happened one time during my testing.

    We also went through the troubleshooting guide and the BLE guide. These are the following details that we caught:

    - VDDS_DCDC does not have a 0.1 uF decoupling capacitor on our custom board

    - Inductor and Cap on DCDC_SW is not in a great placement on our custom board. See screenshots for our placement.

    10uH inductor (L4) is not placed very close to pin 33.

    10uF capacitor C13 is not placed very close to pin 33.

    Thanks,

    Paul

     

  • Having an issue including screenshots, lets try this again...

  • Hi,

    Still waiting on a response on the additional information I provided. Could this 180 uA remaining current draw indicate that there is a peripheral that is not shutting down? Is this something I can attempt to resolve with a software tweak (example: manually shutting down each peripheral instead of relying on power_shutdown(null, 0) ) ?