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.

CC2652R: Thread SED current consumption

Part Number: CC2652R

Hello,

I need help concerning the low power state with the CC2652R.

We are using a custom pcb for testing purposes. The firmware is based on the empty_mtd example provided and built our application on top of that. Now I measured the current consumption and recognized that there was a steady current of about 1,7mA also when the device should be in deep sleep.

I started debugging and recognized in the registers that all peripherals that I use are closed properly. I looked at the PDCTL0 and PDCTL1 registers. There I saw that the PERIPH_ON was set to 1. After this I saw that the CRYPTO_CLK_EN in the SECDMACLKGDS register was also set to 1. As I do not directly use any crypto driver I looked into the otstack files. The AESECB_handle was not null and I saw that the counter (ref_num) used in aes_alt.c was also set to 1. Because of this I think that the AES driver might be the case why my device cannot go to standby mode.

Does this make sense or may there be any other reason? If it is true, why does the stack does not close this when the devices enters standby?


I am using the latest SDK (5.10) and also the latest CCS version.

Regards

  • Hi,

    I did a quick sanity test, and at least for the temp_sensor MTD, I am seeing a similar issue (removing UART prints, but leaving the button GPIO configuration) -- about 1.6 mA. This is using the Button.h/c files (which offers an abstraction to the GPIO_* drivers, plus extra functionality such as blinking).

    After I used straight access to GPIO_* functions directly from application (tempsensor.c), I am seeing ~ 0.018 current consumption -- not completely sure where the issue is at the moment.

    This may be the issue you are seeing -- are you using the Button.h/c module ?

    Are you measuring current consumption before or after your MTD has joined a network ?

    Have you tried measuring current consumption using this exact same code, but on a launchpad ?

    Thanks,
    Toby

  • Hi Toby,

    In my application I do not use the Button Module. I implemented all gpio in the straight way as you did in your improvement.

    I measured the consumption when the MTD already joined the network. Would be interesting if it is still too high before it joins the network.

    No, I did not try to measure the current consumption on a launchpad beacause of hardware dependencies. But I can exclude hardware errors because it was already working with this hardware in a former test.

    Regards

  • But I can exclude hardware errors because it was already working with this hardware in a former test.

    To help my understanding here:

    • Does this mean that you've measured expected low current consumption on this custom PCB ?
      • If yes, can you share which SDK this was (if not 5.10) ?
    • Have you tried running a simple standby example (device only sleeps, no peripherals enabled) ?

    Checking the registers on my end, I do see that CRYPTO_CLK_EN == 1, but PERIPH_ON == 0.
    Can you share a snapshot of the registers ? (The PRCM category should be sufficient for now).
    This is what I see on my end:

    PRCM	Power, Reset and Clock Management	
    	INFRCLKDIVR	0x00000000	Infrastructure Clock Division Factor For Run Mode [Memory Mapped]	
    	INFRCLKDIVS	0x00000000	Infrastructure Clock Division Factor For Sleep Mode [Memory Mapped]	
    	INFRCLKDIVDS	0x00000000	Infrastructure Clock Division Factor For DeepSleep Mode [Memory Mapped]	
    	VDCTL	0x00000001	MCU Voltage Domain Control [Memory Mapped]	
    	CLKLOADCTL	0x00000002	Load PRCM Settings To CLKCTRL Power Domain [Memory Mapped]	
    	RFCCLKG	0x00000001	RFC Clock Gate [Memory Mapped]	
    	VIMSCLKG	0x00000003	VIMS Clock Gate [Memory Mapped]	
    	SECDMACLKGR	0x00000001	SEC (PKA And TRNG And CRYPTO) And UDMA Clock Gate For Run And All Modes [Memory Mapped]	
    	SECDMACLKGS	0x00000001	SEC (PKA And TRNG And CRYPTO) And UDMA Clock Gate For Sleep Mode [Memory Mapped]	
    	SECDMACLKGDS	0x00000000	SEC (PKA And TRNG and CRYPTO) And UDMA Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	GPIOCLKGR	0x00000001	GPIO Clock Gate For Run And All Modes [Memory Mapped]	
    	GPIOCLKGS	0x00000001	GPIO Clock Gate For Sleep Mode [Memory Mapped]	
    	GPIOCLKGDS	0x00000001	GPIO Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	GPTCLKGR	0x00000000	GPT Clock Gate For Run And All Modes [Memory Mapped]	
    	GPTCLKGS	0x00000000	GPT Clock Gate For Sleep Mode [Memory Mapped]	
    	GPTCLKGDS	0x00000000	GPT Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	I2CCLKGR	0x00000000	I2C Clock Gate For Run And All Modes [Memory Mapped]	
    	I2CCLKGS	0x00000000	I2C Clock Gate For Sleep Mode [Memory Mapped]	
    	I2CCLKGDS	0x00000000	I2C Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	UARTCLKGR	0x00000001	UART Clock Gate For Run And All Modes [Memory Mapped]	
    	UARTCLKGS	0x00000001	UART Clock Gate For Sleep Mode [Memory Mapped]	
    	UARTCLKGDS	0x00000001	UART Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	SSICLKGR	0x00000000	SSI Clock Gate For Run And All Modes [Memory Mapped]	
    	SSICLKGS	0x00000000	SSI Clock Gate For Sleep Mode [Memory Mapped]	
    	SSICLKGDS	0x00000000	SSI Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	I2SCLKGR	0x00000000	I2S Clock Gate For Run And All Modes [Memory Mapped]	
    	I2SCLKGS	0x00000000	I2S Clock Gate For Sleep Mode [Memory Mapped]	
    	I2SCLKGDS	0x00000000	I2S Clock Gate For Deep Sleep Mode [Memory Mapped]	
    	SYSBUSCLKDIV	0x00000000	Internal. Only to be used through TI provided API. [Memory Mapped]	
    	CPUCLKDIV	0x00000000	Internal. Only to be used through TI provided API. [Memory Mapped]	
    	PERBUSCPUCLKDIV	0x00000000	Internal. Only to be used through TI provided API. [Memory Mapped]	
    	PERBUSDMACLKDIV	0x00000000	Internal. Only to be used through TI provided API. [Memory Mapped]	
    	PERDMACLKDIV	0x00000000	Internal. Only to be used through TI provided API. [Memory Mapped]	
    	I2SBCLKSEL	0x00000000	I2S Clock Control [Memory Mapped]	
    	GPTCLKDIV	0x00000000	GPT Scalar [Memory Mapped]	
    	I2SCLKCTL	0x00000000	I2S Clock Control [Memory Mapped]	
    	I2SMCLKDIV	0x00000000	MCLK Division Ratio [Memory Mapped]	
    	I2SBCLKDIV	0x00000000	BCLK Division Ratio [Memory Mapped]	
    	I2SWCLKDIV	0x00000000	WCLK Division Ratio [Memory Mapped]	
    	RESETSECDMA	0x00000000	RESET For SEC (PKA And TRNG And CRYPTO) And UDMA [Memory Mapped]	
    	RESETGPIO	0x00000000	RESET For GPIO IPs [Memory Mapped]	
    	RESETGPT	0x00000000	RESET For GPT Ips [Memory Mapped]	
    	RESETI2C	0x00000000	RESET For I2C IPs [Memory Mapped]	
    	RESETUART	0x00000000	RESET For UART IPs [Memory Mapped]	
    	RESETSSI	0x00000000	RESET For SSI IPs [Memory Mapped]	
    	RESETI2S	0x00000000	RESET For I2S IP [Memory Mapped]	
    	PDCTL0	0x00000000	Power Domain Control [Memory Mapped]	
    	PDCTL0RFC	0x00000000	RFC Power Domain Control [Memory Mapped]	
    	PDCTL0SERIAL	0x00000000	SERIAL Power Domain Control [Memory Mapped]	
    	PDCTL0PERIPH	0x00000000	PERIPH Power Domain Control [Memory Mapped]	
    	PDSTAT0	0x00000000	Power Domain Status [Memory Mapped]	
    	PDSTAT0RFC	0x00000000	RFC Power Domain Status [Memory Mapped]	
    	PDSTAT0SERIAL	0x00000000	SERIAL Power Domain Status [Memory Mapped]	
    	PDSTAT0PERIPH	0x00000000	PERIPH Power Domain Status [Memory Mapped]	
    	PDCTL1	0x00000000	Power Domain Control [Memory Mapped]	
    	PDCTL1CPU	0x00000000	CPU Power Domain Direct Control [Memory Mapped]	
    	PDCTL1RFC	0x00000000	RFC Power Domain Direct Control [Memory Mapped]	
    	PDCTL1VIMS	0x00000000	VIMS Mode Direct Control [Memory Mapped]	
    	PDSTAT1	0x0000001A	Power Manager Status [Memory Mapped]	
    	PDSTAT1BUS	0x00000001	BUS Power Domain Direct Read Status [Memory Mapped]	
    	PDSTAT1RFC	0x00000000	RFC Power Domain Direct Read Status [Memory Mapped]	
    	PDSTAT1CPU	0x00000001	CPU Power Domain Direct Read Status [Memory Mapped]	
    	PDSTAT1VIMS	0x00000001	VIMS Mode Direct Read Status [Memory Mapped]	
    	RFCBITS	0xE0000091	Control To RFC [Memory Mapped]	
    	RFCMODESEL	0x00000000	Selected RFC Mode [Memory Mapped]	
    	RFCMODEHWOPT	0x0000000F	Allowed RFC Modes [Memory Mapped]	
    	PWRPROFSTAT	0x00000000	Power Profiler Register [Memory Mapped]	
    	MCUSRAMCFG	0x00000020	MCU SRAM configuration [Memory Mapped]	
    	RAMRETEN	0x00000008	Memory Retention Control [Memory Mapped]	
    	OSCIMSC	0x00000000	Oscillator Interrupt Mask [Memory Mapped]	
    	OSCRIS	0x000000FB	Oscillator Raw Interrupt Status [Memory Mapped]	
    	OSCICR	0x00000000	Oscillator Raw Interrupt Clear [Memory Mapped]	
    

    Can you also describe the overall network traffic during the test?
    E.g how often is the SED transmitting/receiving packets.

    My test setup is relatively simple -- the SED polls every 2 seconds and sends reports every 10 seconds.

  • Hi,

    We already found the issue. I measured the low current on the similar board with another mcu. I then tried to use the empty example to assure that the mcu is really in deep sleep before making any further progress on the software side. To put a long story short we recognized that there were two additional components placed on this pcb in comparison to the older pcb. Removing them solved the problem.

    After that problem was solved I was able to see on the oscilloscope that the device is not sleeping for some seconds at startup but afterwards sleeps very well. This also means that it was correct that some clocks were still activated at the point in time shortly after the startup.

    Nevertheless, thanks for your tips and your help!

  • Glad to hear!

    Thanks for the update.