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.

CC1352P: Unusual Current Draw After Programming Without Power Cycle

Part Number: CC1352P

Our product, a custom PCB based on the CC1352P will be powered by a non-removable batter. After applying the battery, we will need to program the device.

When I program the PCB (or a CC1352 development board) using external power, then remove the programming device, the current draw is not as expected. The current draw is higher than it should be and there are no small peaks (which I understand occur because the chip is charging a capacitor on a regular schedule). If I then cycle the power, the current usage is lower, and I see the small peaks that I expect.

Below is a picture of the current draw during programming, then after programming is complete and the program is executing.

Below is a picture of the current draw after cycling the power.

I am running a simple example program that toggles an LED to try and diagnose my problem. I am using TI-RTOS.

GPIO_setConfig(CONFIG_GPIO_L, GPIO_CFG_OUT_STD | GPIO_CFG_OUT_LOW);
sleep(3);
bool on=1;
while(1) {
sleep(3);
GPIO_write(CONFIG_GPIO_L, on);
on = !on;
}

Is it possible to achieve the lower current draw seen in my second image without cycling the power? If so what changes need to be made?

Note: It's hard to completely rule out some sort of hardware issue or peripheral issue that causes the higher current draw. However, I suspect the actual CC1352 module is responsible for the increased current draw because the program does execute, but I do not see the peaks where the capacitor is charging. That would seem to indicate the CC1352 is in some sort of strange power state until power is cycled.

  • More details. It also seems certain power commands do not execute correctly after programming but before cycling power. For example, after I program the device Power_shutdown(0, 0) does not work as expected. It causes the current to rise further.

    Also HWREGBITW(AON_PMCTL_BASE + AON_PMCTL_O_RESETCTL, AON_PMCTL_RESETCTL_SYSRESET_BITN) = 1 which is essential SysCtrlSystemReset() does not reset the device It also sends the device into some unresponsive higher power consumption.

    Perhaps there are debugger settings I can change. My guess is the device is in some state where It can talk and respond to JTAG or debugging events. I suspect the watchdog timer also would not reset the device as is the case when debugging.

  • Hi,

    Can you try this with launchpad to see if same thing happens?

    Thanks

  • Yes. I see the same behavior with the Launchpad.

  • Resolved. It seems JTAG power accounts for the rise in current I am seeing. When the device is programmed and removed from the programmer, the JTAG power stays on. Additionally, this will prevent the device from entering shutdown more or resetting.

    One can check if the JTAG is powered with AONPMCTLPowerStatusGet() & AONPMCTL_JTAG_POWER_ON.

    On the CC13x2. JTAG power can not be turned off with software. My solution is to short the JTAG reset pin to ground for a second after programming and removing the device from the programmer. This will force a restart where the JTAG is not powered without having to do a power cycle.

    Hope this helps someone in the future!