cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC™ 4

Anonymous
Not applicable

Hi, I've used one of the low power code examples, putting the node in deep sleep mode between each communication, and I was expecting to see a consumption of a few micro amps during that time, but I'm observing about 500 micro amps as the base consumption. As I am already putting the debug pins as GPIO to reduce the power consumption, the debug is very limited, any tip on how to debug in this case? What could be using 500 micro amps when not receiving or transmitting? This is the scope screenshot, what is worrying me is the base value, because the higher consumption part is only 2.8ms long, the base value will have the highest impact on the battery usage and I need to reduce it to a few micro amps. I've already removed all the additional HW, so the battery is only powering the CYBLE-022001-00 module directly through a 10 ohm resistor (to measure the current with the scope) ferrite beads and decoupling capacitors (2 x 1uF).

Any tip will be very welcome 🙂

Best regards

Fernando

SDS00003.BMP

0 Likes
1 Solution
Anonymous
Not applicable

Hi, just to thank everyone for the support, the problem is solved. As  I said, the schematic is not mine, and I found that there is a voltage regulator that in some situations has no power on its input, but the enable pin is controlled by the PSOC, and if the enable pin is on with the voltage regulator without power, the enable pin uses these 500uA, so the mystery is solved, by using very simple code (I used the Eddystone beacon example code, and it used almost no power during the inactivity period with the same HW) and then changing it in order to make it closer to the real app.

Best regards

Fernando

View solution in original post

13 Replies
Anonymous
Not applicable

Yes, the Cypress low power example project had already the Programming/Debugging / Debug Select as GPIO, this is why it isn't easy to debug the project. What could be using 500 uA? The example project calls ManageBlePower that is an alias for CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP), so the BLESS subsystem should go to deep sleep, and then it calls ManageSystemPower() and as the applicationPower flag is set to DEEPSLEEP, the CPU should also go to deep sleep mode, as CySysPmDeepSleep() function is called

Any idea of what could be going wrong?

Best regards

Fernando

0 Likes
Anonymous
Not applicable

Having gone through this with a PSOC recently I know the pain!

I did get down to the ~6uA level in the end, SWD as GPIO was the last thing I fixed, but I also had to put various pins in to pull up/down/open drain mode which had an impact before finding the SWD setting.

The other thing to do is check what else is on the board - VReg being a possible explanation, a voltage divider, pin left as high or low with pull-up/down that allows power to drain elsewhere, e.g. a very dim LED or through another chip.

Good luck!

0 Likes
Anonymous
Not applicable

Thank you very much for your reply! I have experience on this problem but with different chip architectures, so the 'tricks' are not the same 🙂

In the past, I have developed wireless sensors with ATMEGA chips that are working for more than one year without changing the battery, and also have made some low power designs with STM32 and SAM4 MCUs, With the PSOC 4 (or PROC 4 in this particular case) it is the first time I need to have a device battery powered, and the HW design, in this case, is not mine (I've been contracted for the FW development, the HW was already developed). I've already isolated the power supply circuit in order to have the minimal number of components powered, and I'm powering the PROC module using a lab power supply, so it has almost no other components involved. There is a voltage divider to measure the battery level that has a bit more than 1M, so there will be a current of a few uA through it (about 3.5uA), Even adding this current, the total current when the PROC is in deep sleep, added to the voltage divider current should be below 10uA, not 500uA. The remaining

I've already isolated the power supply circuit in order to have the minimal number of components powered, and I'm powering the PROC module using a lab power supply, so it has almost no other components involved. There is a voltage divider to measure the battery level that has a bit more than 1Mohm impedance, so there will be a current of a few uA through it (about 3.5uA), Even adding this current, the total current when the PROC is in deep sleep, added to the voltage divider current should be below 10uA, not 500uA. The remaining components are 2 decoupling capacitors (1uF, ceramic), 2 ferrite beads and 2 LEDs connected to GPIO pins through 24 ohm resistors, but the pins are set to 'OFF' so there should be no current through the LEDs. The remaining pins are unconnected. Is there any recommendation to set these unused pins in any specific mode in order to reduce the power consumption? I didn't configure any of the unused pins in the PSOC Creator, only configured the 2 LED GPIO pins as push pull. The supply of the PROC module is done through VDD and VDDR, each of it through a separate ferrite bead and a decoupling capacitor.

Re-examining again the code I got a doubt: I'm configuring a watchdog interrupt every 500us and defining a callback to it, where I do some application timer management (just change some internal variables, and once per minute read the ADC, but it has no interaction with the bluetooth part). If the MCU was in deep sleep before the watchdog timeout, it will automatically go to deep sleep again after the watchdog callback executes, or the callback itself should put the CPU again in deep sleep when it exits?

     CySysWdtSetInterruptCallback(CY_SYS_WDT_COUNTER0,wdtInterruptCallback);

Best regards

Fernando

0 Likes
Bob_Marlowe
Expert II

The WDT interrupt and the following callback will get the CPU out of deep sleep. There is no automatism, you need to send your device to sleep again.

Do not do that within the interrupt or callback handler, you will end up in pending interrupts and stack overflow!

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

Thanks for your answer, I'll try to add some debug toggling a pin in order to check the real behavior, but I think that when the WDOG takes the CPU out of deep sleep every 500us, the main loop code will run and should put it again in deep sleep, the ManageSystemPower function puts the CPU in deep sleep calling CySysPmDeepSleep(). This is the main loop code (as in the Cypress low power example):

    /***************************************************************************

    * Main polling loop

    ***************************************************************************/

    while(1)

    {

        /***********************************************************************

        *  Process all BLE events from the BLE component

        ***********************************************************************/

        RunBle();

        /***********************************************************************

        *  Put BLE sub system in DeepSleep mode when it is idle

        ***********************************************************************/

        ManageBlePower();

   

        /***********************************************************************

        *  Run your application specific code here

        ***********************************************************************/ 

        if(applicationPower == ACTIVE)

        {

            RunApplication();

        }

       

        /***********************************************************************

        *  Process application power modes

        ***********************************************************************/

        ManageApplicationPower();  

       

        /***********************************************************************

        *  Manage system power mode based on application and BLE power modes

        ***********************************************************************/

        ManageSystemPower();

    }

Best regards

Fernando

0 Likes
Anonymous
Not applicable

Make sure you are clearing the watchdog timer interrupt on wakeup/interrupt. Otherwise, you will never go back to sleep due to the interrupt always pending.

0 Likes
Anonymous
Not applicable

Thanks for your answer, I'm using the watchdog callback method so I think that the clear the interrupt is not needed:

CySysWdtSetInterruptCallback(CY_SYS_WDT_COUNTER0, wdtInterruptCallback);

Nevertheless, I tried to add the interrupt clear inside the callback and the result was the same:

void wdtInterruptCallback()

{

     CySysWdtClearInterrupt(CY_SYS_WDT_COUNTER0_INT);

     ...

I also tested removing the call to CySysWdtSetInterruptCallback, so the callback was not called and the result was also the same, about 500uA base consumption.

Any other ideas? What could be using a constant current value of around 500uA? This value is constant between each advertisement period if not connected, or until the periodic transmission when connected. If the CPU wasn't sleeping or the BLE radio wasn't sleeping we will observe a higher value, right? So it must be other thing using that power...

Best regards

Fernando

0 Likes
Anonymous
Not applicable

0.5 mA or 500 uA is alot of power missing...

It could be a hardware issue with a resistor draining from power to ground or something similar;

As user_464999847 mentioned, disabling the pin GPIOs before sleep mode will reduce current if those are pushing current out.

If you have a debugger kit, you could try writing a simple test program that does nothing except put the CPU directly into deep sleep to see if it is a software issue or a hardware issue with your board setup.

If you narrow it down to a software issue, then you can slowly add back in components/functionality one step at a time to see what is causing the spurious current draw. I would start with the CPU power first, then the BLE radio, and finally start adding back in your application. Also, it is possible that test hardware might be the cause if it is not a software issue

0 Likes
Anonymous
Not applicable

Thank you for your email, I agree that the difference is very high and it might be some issue with the HW. I have the schematic and taking it in consideration I have removed the connection to the voltage regulator, so I'm powering directly the PROC module (CYBLE-022001-00). The only remaining HW are 2 decoupling capacitors, and a voltage divider to measure the supply voltage, and that voltage divider has more than 1MOhm, so it will drain a few uA more, but only about 3uA, so I was expecting less than 10uA total, not 500uA!

I was going exactly in the direction you suggested, having the simplest possible code to validate the HW, putting the CPU to sleep as soon as possible. Can you suggest a simple example to be sure that the example used has the expected behavior? The one I was going to use is this: BLE/BLE Low Power Template Examples/BLE_LED_Blinky.cydsn at master · cypresssemiconductorco/BLE · Gi... , is there another example more adequate to do the test? I intend to define DEEPSLEEP_ONLY to 1 in this example and to run the test and measure the consumption:

#define DEEPSLEEP_ONLY   1

Any recommendation or suggestion for a more appropriate example code?

Best regards

Fernando

0 Likes
Anonymous
Not applicable

That is pretty close, but I would simplify it to have just:

int main() {

     while(1) {

     CySysClkEcoStop();

     CySysPmDeepSleep();

     }

}

0 Likes
Anonymous
Not applicable

Hi, just to thank everyone for the support, the problem is solved. As  I said, the schematic is not mine, and I found that there is a voltage regulator that in some situations has no power on its input, but the enable pin is controlled by the PSOC, and if the enable pin is on with the voltage regulator without power, the enable pin uses these 500uA, so the mystery is solved, by using very simple code (I used the Eddystone beacon example code, and it used almost no power during the inactivity period with the same HW) and then changing it in order to make it closer to the real app.

Best regards

Fernando

View solution in original post

Anonymous
Not applicable

I would recommend trying to change the LED pins to high impedence analog mode prior to going to sleep.

0 Likes