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