LAUNCHXL-CC1352P: do unused pins on launchpad draw current?

Hi Zhiyong,

1 mA seems way too much to be only GPIO leakage current.

Could you please provide a capture of EnergyTrace++? The device will not go in standby mode with EnergyTrace enabled, but we can see if a peripheral is being left on.

Also, did you start from a CC1352P 15.4 example?

Regards,

Arthur

Hi Arthur,

Thanks for your reply. Somehow EnergyTrace++ is somehow greyed out when I tried to enable it in CCS. According to this page, the embedded XDS110 on CC1352P1-launchpad does support ET++. If I restart CCS, ET++ option will be available, but once I try to use it, it will quit, then becomes unavailable. Any idea why it is not available? The board being too old?

To answer your other question, yes, I started with 15.4 sensor example, then copied all the files that we need to change into project folder and made changes there.

Regards,

ZL

Arthur R☑️ said:

The device will not go in standby mode with EnergyTrace enabled

Is there a way to measure current draw with the embedded XDS110? Something like using XDS110 on one board to power and measure another board?

Hi Zhiyong,

The customer also has to enable 4-pin cJTAG in the targetConfig ccxml file.

The problem with EnergyTrace++ is that it will leave the JTAG power domain on, thus prevent the device from going to sleep anyway.

Regards,

Arthur

Hi Arthur,

I just realized the 4-pin cJTAG requirement, but that doesn't make a difference. ET++ still greys out once I try to use it. But I think ET++ will give a good idea what peripheral is still on.

I recall having issues with ET++ several years ago, but don't remember what was done to get it to work.

Thanks,

ZL

Finally get it to work. I need to set ET/ET++ as auto launch and let it start with debug, not trying to launch ET by itself.

There seems not be many peripheral on, and RxWait time is also minimum. Can I conclude the excessive current draw is either external to CC1352P MCU or an artifect of measurement?

Hi Zhiyong,

In order to rule out artifacts from measurements, we can run a calibration of the EnergyTrace prior to taking measurements.
The procedure is described page 26 of this Application Note: https://www.ti.com/lit/an/swra478d/swra478d.pdf

Let me know of the results.

Regards,

Arthur

Hi Arthur,

By following the instructions in the application note to the T, I got the following result:

The overall average and also min current draw are both smaller than previous measurements, but the floor at ~0.89mA still exists. I also run the unmodified 15.4-sensor example, with POWER_MEAS on, and POWER_TEST_PROFILE == SLEEP, I get the following result:

So there seems to be some amount of current leakage on the launchpad. I compared the schematics of CC1310 and CC1352P1 launchpad, the circled two pullup resistors are not populated in CC1310-launchpad. Other than these two, I don't see any other differences. Could these two PU resistors the culprit?

Hi Arthur,

I did turn off CUI_MODULE by changing the entry in sensor.opts

-DCUI_DISABLE
-DxCUI_POSIX

I also removed buttons and LEDs, and the associated GPIOs in syscfg.

We do use UART, but UART is closed as soon as related operation is complete. This is confirmed in ET++ traces and also current trace in ET. Our measurement with CC1310 launchpad configured into frequency hopping mode also matches the numbers in the article you referenced.

Let me see if we can reproduce the numbers with CC1352P-launchpad configured into frequency hopping mode with unmodified sensor example code.

Thanks,

ZL