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