3mA in DeepSleep - power consumption way too high

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am attempting to achieve sub 30uA quiescent current for a prototype using a Cypress PSoC 42xx CY8C4247LQI-BL483.

   

I am using the BLE Pioneer baseboard measuring across the BLEVDD/VDD link jumper. I have verified my meter reads zero with the PSoC module removed from the baseboard.

   

With this set up I am measuring 17mA in a while(1) loop, which seems reasonable for the processor when running. The problem is deep sleep.  I'm measuring about 3mA after executing CySysPmDeepSleep(), this high current is significantly higher than stated in the datasheet (approx 1.7uA + peripherals in the datasheet)

   

I can wake up properly from deep sleep using a watchdog and this appears to work normally (i.e. processor current returns to 17mA previously measured)

   

I've tried turning off the analog and UART blocks. These being on seemed to increase current by ~2mA but I can't account for the rest of the power usage.

   

Any advice appreciated.

0 Likes
1 Solution
Anonymous
Not applicable

tom66,

   

 

   

In your project, I see that you have ECO enabled (CYDWR -> Clocks). This is contributing to major part of your current consumption after going to deep sleep.

   

As you are not using BLE, you can run on IMO (which you are actually running on). Disable ECO in one of the following two ways:

   

1) Uncheck the box for ECO in CYDWR -> Clocks tab -> Double click on ECO. Rebuild the project

   

2) Call 'CySysClkEcoStop()' API in main.c, either at start or before calling the deep sleep API.

   

You may also want to set the VDDD and VDDA voltage to 3.3 V in CYDWR -> Systems tab, if that is the voltage you are working on.

   

I would also suggest to set the drive mode of the digital output lines to HiZ when not in use, specially LED. 

View solution in original post

0 Likes
34 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Welcome in the forum.

   

Did you switch off the debugging capabilities by selecting "GPIO" for debugging pins in the "System"-tab of cydwr-file?

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Thanks Bob for the quick reply. I have just tried that and it doesn't seem to have made any difference.

   

To add further information I have attached a pic of my clocks.  I am using the UART module, two interrupts (LPComp12 and WDT), two low power comparators and one opamp. I have tried removing the initialisation code to see if these were problematic but this does not seem to have helped. I also tried adding the relevant _Sleep() commands in.

   

http://i.imgur.com/6qdZkoa.png 

   

http://i.imgur.com/qV05G55.png

   

Thanks,

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can you post your complete project, so that we all can have a look at all of your settings? To do so, use
Creator->File->Create Workspace Bundle (minimal)
and attach the resulting file.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

There may be confidentiality issues involved with doing that unfortunately. Are there any areas you would be particularly interested in? The code is copyrighted, so I can't include that I'm afraid. Their rules, not mine.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Have you seen these -

   

 

   

http://www.cypress.com/?rID=78797     AN86233 - PSoC® 4 Low-Power Modes and Power Reduction Techniques

   

http://www.cypress.com/?rID=96072     AN90114 - PSoC® 4000 Family Low-Power System Design Techniques

   

http://www.cypress.com/?rID=110007     AN92584 - Designing for Low Power and Estimating Battery Life for BLE Applications

   

http://video.cypress.com/video-library/search/psoc+4+low+power/

   

 

   

Regards, Dana.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Thanks for the links. I have read through the first one before, and it's the guide I followed in implementing it. I'm not sure, but I don't think you can enter deep sleep from within an ISR? I kept getting the processor locking up when entering from the ISR, so I changed it to a flag check in the main loop. If the flag is set, the flag is cleared and the processor goes into deep sleep on that loop iter. An ISR wakes up the processor from deep sleep and sets the flag if the CPU should sleep. All this works as expected but quiescent current is far too high (though, it does at least change so -something- is going on.)

   

I tried project AN86233_LPComp and using the Pioneer board I am still getting 1.4mA. I had to make some small modifications, I have attached the project file (this should work with CY8C4247LQI-BL483). This isn't my project but since it has a similar issue maybe it'll help.

   

I wonder if it could be a measurement error caused by the base board? Or can anyone see an issue with how I have "converted" the project - I just changed device and unlocked pins and it built fine...

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

This thread might help -

   

 

   

http://www.cypress.com/forum/psoc-4-ble/power-consumption-issue?source=search&keywords=ble%20power&c...

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

I noticed the project wakes up once / sec. A meter measuring in uA and lower range

   

has a settling time spec, possibly wake up processor every 100 sec to obviate that issue ?

   

Otherwise you are going to do a complex averaging of sleep and wakeup currents.

   

 

   

One method, if you have a psoc 3 or 5LP board is use it to do a triggered measurement,

   

would be good to 20 bits, and can handle voltages 100 mV outside rail which enables

   

sense R in supply lead or ground.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

tom66,

   

 

   

In your project, I see that you have ECO enabled (CYDWR -> Clocks). This is contributing to major part of your current consumption after going to deep sleep.

   

As you are not using BLE, you can run on IMO (which you are actually running on). Disable ECO in one of the following two ways:

   

1) Uncheck the box for ECO in CYDWR -> Clocks tab -> Double click on ECO. Rebuild the project

   

2) Call 'CySysClkEcoStop()' API in main.c, either at start or before calling the deep sleep API.

   

You may also want to set the VDDD and VDDA voltage to 3.3 V in CYDWR -> Systems tab, if that is the voltage you are working on.

   

I would also suggest to set the drive mode of the digital output lines to HiZ when not in use, specially LED. 

0 Likes
Anonymous
Not applicable

@dana,

   

I am using a precision 6.5 digit bench multimeter to do the measurement which takes an average measurement over several seconds. I did also try disabling all wakeup interrupts which did not seem to make any significant difference to the power consumption so I do believe the power usage is primarily due to the deepsleep mode using too much power.

   

@roit

   

Thanks for the information. I will try that later tonight and update.

   

Please note, the project file I have uploaded is one from Cypress code examples, it is not my exact project but shows the same issue with high quiescent power usage after entering deep sleep.

   

Thanks all for the responses, very helpful.

0 Likes
Anonymous
Not applicable

tom66,

   

I would advise to look at application note AN92584 for low power operation pertaining to BLE:

   

http://www.cypress.com/documentation/application-notes/an92584-designing-low-power-and-estimating-ba... 

   

The BLE device (PSoC 4 BLE/PRoC BLE) have some requirements with respect to clock (ECO/WCO) which have to be handled. As you will see, PSoC 4 BLE has ECO enabled by default, but as you are not using BLE it is not required. You have to either disable it from CYDWR or call the _stop() API for lower power consumption.

Anonymous
Not applicable

Thanks Roit. I do intend to use BLE later on though, although only very infrequently. I presume the BLE module clock can be turned on and off as required. 

0 Likes
Anonymous
Not applicable

Yes. 

   

You can enable the clocks only when you require BLE and disable other times.

Anonymous
Not applicable

Thanks for the info. By shutting off the IMO, I am now down to 310uA. Looks a lot more reasonable, but is still too high!

   

I noticed when I brought my fingers near the GPIO pins, the current varied quite a lot. Could this be due to some pin leakage effect, maybe undefined logic? Without creating 30+ pins in PSoC creator, what is the best way to set all unused pins to output drive LOW?

   

I switched to a handheld meter for measurement. It has a lower resolution, but updates faster. I can see the current increase briefly when the WDT ISR is entered. I'm also making the WDT ISR flash a red LED for 0.5ms which is visible so I know the ISR is working and the processor can enter and exit deepsleep.

   

Thanks again

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Try an "empty"design as a calibration point, no components used, all the

   

recommendations of the ap notes and above clock recommendations, then

   

see what you get. Also try a current measurement with no power to the design,

   

see what your DVM yields. This will eliminate or determine if there are any

   

thermoelectric effects, see -

   

 

   

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CDkQFjAAahUKEwjX...

   

 

   

If you have a pin at HiZ, and capacitively couple an E field to the pin,

   

like line based AC, that can drive a pins protection diodes into conduction,

   

get above datasheet albeit light conduction. But thats enough to exceed

   

datasheet numbers. Try a faraday cage over the project, see what happens.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Looks like you might be on to something there Dana. I built a very primitive Faraday box - a tinfoil lined box. Putting it over the project dropped the quiescent current by over 100uA!

   

That's a significant amount. I also found that if I turned off my LED lighting in the lab, the quiescent current also fell. The lighting runs off a standard 230V, 50Hz supply using a simple series capacitive ballast.

   

I've not yet been able to achieve the mythical 30uA. But, this is obviously a contributing factor.

   

Now the question is... how do I make unused GPIOs all drive ground? Without creating a separate pin object for each in PSoC creator... Is there a  way to set a default POR value for all the pins, that can then change as the PSoC initialises?

   

Thanks

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

From this ap note -

   

 

   

 

   

7.3 Startup and Low-Power Behavior

   


On reset/power-up, all GPIO pins start up in the high-impedance analog mode, that is, with input buffer and output
driver disabled. It remains in this mode until the reset is released. Then, each pin is set to its initial configuration
before invoking the main()function.
 

   

http://www.cypress.com/?rID=93401     AN86439 - PSoC® 4 - Using GPIO Pins

   

 

   

Also per port APIs -

   


Cypress provides a set of API functions that you can use to control GPIOs dynamically through the firmware. The API
for the Pins Component enables access on both a Component-wide and per-pin basis. See the ―API‖ section of the
Pins datasheet for more details.

   


Per-pin API functions, which are provided as part of cy_boot in the cypins.h file, are documented in the ―Pins‖
section of the PSoC Creator System Reference Guide (Help > Documentation > System Reference). You can use
these functions to control the configuration registers for each physical pin.
 

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

The analog high impedance mode, is that a mode that would be sensitive to external noise causing logic to toggle or consume extra power due to an internal following buffer?

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

No.

   

 

   

From the TRM -

   

 

   

 

   

7.3.1 High-Impedance Analog

   


High-impedance analog mode is the default reset state; both
output driver and digital input buffer are turned off. This state
prevents an external voltage from causing a current to flow
into the digital input buffer. This drive mode is recommended
for pins that are floating or that support an analog voltage.
High-impedance analog pins cannot be used for digital
inputs. Reading the pin state register returns a 0x00 regard
less of the data register value.

   


To achieve the lowest device current in low-power modes,
unused GPIOs must be configured to the high-impedance
analog mode.

   

 

   

The only way the pin would draw any current is if the protection diodes were turned on

   

by forcing the pin outside power supply rails by a diode drops worth of voltage. So if

   

you had high noise fields there is a possibility of them forcing conduction. Poor board

   

layout, shielding, severe EMI environment......

   

 

   

Regards, Dana.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Thanks for the reference again. So I think that would rule out the issue, as I have only touched the LED pins, and they are set as drive outputs high/low.

   

I stripped away all the unnecessary stuff from the project. Just the WDT and ISR waking up every 2 seconds or so. Still drawing this high current. Still affected by external fields, as tinfoil box reduces current.

   

Really at a loss here to explain this, tempted to start from scratch and add stuff in until it breaks. 

   

I've attached my reduced project that has all proprietary bits removed (the analog design) - if anyone has any ideas, I'm all ears!

   

Thanks,

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I would suggest you to update your Creator to version 3.2 and put the control register into sleep before entering deep sleep.

   

 

   

Bob

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Looks like control reg sleep command only saves status, so may not

   

effect power per se. Maybe the PLD block powered down by main

   

sleep command ?

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

After doing some further debugging, I believe it is my LED control (including control reg) which is using high quiescent current.

   

By removing this part of the code, I can get down below 1uA. WDT still works as I can see brief quiescent current increase as it wakes up.

   

Is there a better way of controlling GPIOs? I can write directly to registers, but is there a way to address it, e.g. like Port2[6] or something. It seems somewhat labour intensive to create a distinct pin object for everything. Not to mention, it seems to use a lot of flash.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

In the help menu, system reference guide, section 6 is a collection of APIs

   

that cover pin control.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

I have read that in my searches before but came out more confused. In the guide, it says:

   

For PSoC 4, there are status registers, data output registers, and port configuration registers only, so the macro takes two arguments: port register and pin number. Each port has these registers addresses defined: CYREG_PRTx_DR CYREG_PRTx_PS CYREG_PRTx_PC The x is the port number, and the second argument is the pin number.

   

How is the second argument specified? CYREG_PRT2_PC is a standard #define, it's not a macro and doesn't accept any arguments...

   

I cannot find a *single* reference to this macro anywhere as taking arguments... nor any code examples.

   

I tried THIS, which I discerned from reading cypins.h:

   
    CY_SYS_PINS_SET_DRIVE_MODE(CYREG_PRT2_PC, 6, CY_SYS_PINS_DM_STRONG);     CY_SYS_PINS_SET_DRIVE_MODE(CYREG_PRT3_PC, 7, CY_SYS_PINS_DM_STRONG);     CY_SYS_PINS_SET_DRIVE_MODE(CYREG_PRT3_PC, 6, CY_SYS_PINS_DM_STRONG);     CY_SYS_PINS_CLEAR_PIN(CYREG_PRT3_DR, 6);     CY_SYS_PINS_CLEAR_PIN(CYREG_PRT3_DR, 7);     CY_SYS_PINS_SET_PIN(CYREG_PRT2_DR, 6);
   

but it sets all the pins in that port high.  I must be doing something wrong. (I just want to light red LED for now.)

   

It seems as if there are plenty of GPIO examples for PSoC 3 and 5, but none for PSoC 4 or 42xx BLE? It uses a different macro structure, and I can't find one example of that usage that I could understand from. How does, for example, CyPins_SetPin work, as it only takes a "name" attribute, and not a pin number?

   

Thanks for your help so far

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

You have seen this ? -

   

 

   

http://www.cypress.com/documentation/application-notes/an86439-psoc-4-using-gpio-pins     AN86439 - PSoC® 4 - Using GPIO Pins

   

 

   

Regards, Dana.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

For this -

   

 

   


CY_SYS_PINS_CLEAR_PIN(CYREG_PRT3_DR, 6);

   

CY_SYS_PINS_CLEAR_PIN(CYREG_PRT3_DR, 7);

   

CY_SYS_PINS_SET_PIN(CYREG_PRT2_DR, 6);

   

 

   

The first sets two bits high, the second 3 bits high, the last 2 bits high.

   

 

   

Regards, Dana.
 

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

CY_SYS_PINS_SET_DRIVE_MODE(portPC, pin, mode)
Description: Sets the drive mode for the pin (DM).
The macro operation is not atomic. It is not guaranteed that the shared register
will remain uncorrupted during simultaneous read/modify/write operations
performed by two threads (main and interrupt threads). To guarantee data
integrity in such cases, the macro should be invoked while the specific interrupt is
disabled or within the critical section (all interrupts are disabled).
Parameters: portPC: Address of port configuration register (uint32). Definitions for each port
are provided in the cydevice_trm.h file in the form: CYREG_PRTx_PC, where x is
a port number 0 - 4.
pin: pin number 0 – 7.
mode: Desired drive mode
Define Source
CY_SYS_PINS_DM_ALG_HIZ Analog HiZ
CY_SYS_PINS_DM_DIG_HIZ Digital HiZ
CY_SYS_PINS_DM_RES_UP Resistive pull up
CY_SYS_PINS_DM_RES_DWN Resistive pull down
CY_SYS_PINS_DM_OD_LO Open drain - drive low
CY_SYS_PINS_DM_OD_HI Open drain - drive high
CY_SYS_PINS_DM_STRONG Strong CMOS Output
CY_SYS_PINS_DM_RES_UPDWN Resistive pull up/down

   

 

   

The macro is CY_SYS_PINS_SET_DRIVE_MODE(), the arguments are not macros.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Right...

   

Are you saying that the PinNumber attribute is actually a binary mask? (it sounds like you are suggesting 6 = 110, 7 = 111, etc. so it will set the last three bits as is)

   

The macro documentation states 0-7, I presume this correlates directly to the PSoC device pins.  The macro also makes sense if it is using this as it shifts "1u" across to the right bits.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The DR API is writing data to the port, so writing 7 to the port decimal is same as 0b00001110.

   

 

   

The other APIs the pin number is just that, that specific pin.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

OK, but the API is implemented like this:

   

#define CY_SYS_PINS_SET_PIN(portDR, pin)     \
            ( *(reg32 *)(portDR) |= (CY_SYS_PINS_PC_DATAOUT << (pin)) )

   

which does not take "pin" as data, but instead bit shifts the CY_SYS_PINS_PC_DATAOUT which is defined as "1".

   

So I'm confused about what you mean?

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

My apologies, I am so used to the PSOC 1 nomenclature that PRTxDR is a address for

   

the data register, and that writes to it are a byte of data. My screwup.

   

 

   

Yes, the pin is the pin number in all the PSOC 4 macros.

   

 

   

Sorry for the confusion.

   

 

   

Regards, Dana.

Anonymous
Not applicable

Thanks for clearing that up. It makes more sense 🙂 Didn't realise the LED outputs on the 42xx pioneer board are active low, as the LED is common anode.  Now it's working and Iq is low.

   

Thanks for all your help, as well as Bob and roit. I'm not sure why the control register was causing problems. But eliminating it seems to have fixed the Iq. I'm now waking up once every 2 seconds, flashing the LED for 50us then going back to sleep, and the Iq is about 2uA average. Pretty good!

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

The LED drive to ground in general always better in CMOS because of mobility in P vs N,

   

and gate drive not fighting source bulk effect in the P channel. Net of this is lower Rdson in

   

the N channel. More LED current available, better control from the series limiting external R.

   

 

   

Regards, Dana.

0 Likes