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.

CC1352R: CC1352R standby - current consumption

Part Number: CC1352R
Other Parts Discussed in Thread: HDC2080, , ENERGYTRACE

Hi,

I'm using the CC1352R rev E in a very simple project for temperature measuring (TI HDC2080 sensor which consumes nanoamps) and sending the result via Bluetooth 5. I'm using the Simplelink SDK in version 2.40. I've measured the power consumption of  external board (Radiocontrolli RCF-CC1352-868 module) using the Energy Trace on my CC1352R-LAUNCHPAD. All the jumpers on the launchpad are disconnected except for 5V (not used) and GND. I power the external board directly from the 3.3V pin from the XDS.

The problem I've got is the current during the sleep mode. The current consumption profile looks like this:

As you can see, there is significant current consumption (mean of 1.43 mA, max - 3mA) between the BLE packet transmission, when the program does nothing and the MCU should go to sleep. The EnergyTrace++ shows that the MCU stays 93% of the time in deep sleep and 6% in main task. From the image it seems that the core is periodically woken up.

I've configured all of the not used GPIO pins as inputs with no pull.

I use the I2C driver for the temperature sensor in this way to save current:

1) i2c_open();
2) i2c_read();
3) i2c_close();

After doing 5 transmissions via BLE advertising, I disable the advertising.

Do you have any idea what can cause such a current draw? Is it possible that the TI RTOS does not use the tickless mode? (tick is configured to be done as in default example - every 10us).

I'm running out of ideas what can happen here.

Best regards,

Konrad

  • To verify that your measurement setup is correct, are you able to recreate the traces shown in chapter 7 in http://www.ti.com/lit/an/swra478d/swra478d.pdf.

  • Hi,

    I've changed the launchpad board to the newer one (with tantalum capacitor), and disconnected unused GPIOs instead of configuring them as inputs. As a result, I've managed to reduce the current usage during sleep mode to the 0,57mA of mean value. However, the current in chart is still noisy. The values change from about 0.30 mA to 0.9mA.
    The same is with the rfPacketTx example - current usage in sleep mode is also noisy, but the high value of the noise i just about 50uA lower.

    So my question is - how accurate is the EnergyTrace probe in low current (nano to micro amps) range?

    Is it possible that updating the BLE stack from 2.40 to 3.20 would decrease the current usage?

    Does the CC1352R bt stack use the TI RTOS in tickless mode by default?

    Best regards,
    Konrad

  • Measuring current with large difference between min and max and in addition be able to measure short current pulses is difficult and is the reason we are using a Agilent DC power analyzer to measure current accurately. 

    I have not worked with EnergyTrace directly myself. The accuracy has been improved for each iteration we have done on the CC13x2/ CC26x2 launchpads but I'm not sure what the current number is (The engineer with the best overview is on vacation). But it has limited accuracy in the uA range in addition to noise. You could verify the standby current by measuring with a multimeter or similar (set long enough sleep) 

  • I've done as you suggested with the multimeter. It seems that the EnergyTrace tool itself introduces the 570uA of mean current. When multimeter was connected to the device and the device was powered on, the mean current was ~0.9uA. When I clicked the button on EnergyTrace plugin to start its measurement, the multimeter immediately showed current increase to the forementioned 570uA . The result was consistent with the one provided by the EnergyTrace tool.

    The test was confirmed on the oscilloscope with the resistor. The mean current during the sleep phase was about 1uA. I'll try to test it again with external tool and post the result here for future reference.

    Thanks and best regards,

    Konrad