BLESS Interrupt while in DeepSleep

[JiWa_1379161]

There seems to be limited information as to what the BLESS is doing while in DeepSleep. I can successfully put the BLESS into DeepSleep followed by placing the MCU into DeepSleep. 

   

The BLE module is configured in the Central Role with a custom profile. It is connected to a peripheral device when I put both BLESS and MCU asleep. Immediately after putting the BLESS and MCU to sleep, it wakes right up. So I am not getting the very low microamps power level I am looking for.

   

The device is supposed to be asleep in very low power until a switch is pressed to wake it up. I can remove all external ISR's from the design and work only with the BLE to troubleshoot the problem and ensure nothing else is waking it up. All tests point to the BLESS is waking up the MCU as soon as it goes to sleep.

   

This is very frustrating and do not undertsand why or what I can do different. It appears that when it is connected to a peripheral, this occurs. If I try without a connection, then I get the expected results and the BLESS stays asleep. Is there a setting or missing code?

   

Here is the basic low power code which I see is used in multiple applications

   

        /* Local variable to store the status of BLESS Hardware block */
        CYBLE_LP_MODE_T sleepMode;
        CYBLE_BLESS_STATE_T blessState;
       uint8 intrStatus;
        
        /* Put BLESS into Deep Sleep and check the return status */
        sleepMode = CyBle_EnterLPM(CYBLE_BLESS_DEEPSLEEP);
        
        /* Disable global interrupt to prevent changes from any other interrupt ISR */
    //    CyGlobalIntDisable;
        intrStatus = CyEnterCriticalSection();      // disable interrupts
        /* Check the Status of BLESS */
        blessState = CyBle_GetBleSsState();
   //     isr_SW1_ClearPending();
    //    SW1_ClearInterrupt();
        if(sleepMode == CYBLE_BLESS_DEEPSLEEP)
        {
            /* If the ECO has started or the BLESS can go to Deep Sleep, then place CPU 
            * to Deep Sleep */
            if(blessState == CYBLE_BLESS_STATE_ECO_ON || blessState == CYBLE_BLESS_STATE_DEEPSLEEP)
            {
                CySysPmDeepSleep();
             }
        }
        else
        {
            if(blessState != CYBLE_BLESS_STATE_EVENT_CLOSE)
            {
                /* If the BLESS hardware block cannot go to Deep Sleep and BLE Event has not 
                * closed yet, then place CPU to Sleep */
                CySysPmSleep();
            }
        }
   
        CyExitCriticalSection(intrStatus);          // re-enable interrupts

[Anonymous]

Some things to keep in mind:

   

When debugging the chip, low power modes are pretty much nonexistent or crash the debugger in my experience.

   

The BLESS will wakeup if it has events pending, thus if you tell it to go to sleep without handling CyBleProcessEvents() then it will wake up immediately.

   

Since the debugger doesn't work with low power modes, I used an LED (or several :3) to test what the chip was doing when (LED 0 is low-power, LED 1 is connection, etc.)

   

The peripherals on the PSoCs will continue running while the debugger is halted; Thus, if you have a breakpoint, the device will hit it, the BLESS will wakeup for the BLE connection while you take "forever" (~200ms) to click the resume button. By the time you resume, it has hit the BLE connection interval "wakeup" signal dozens of times and will immediately wakeup the device again upon going back to low-power mode.

   

The BLE chip needs to wake up every x ms to "keep-alive" with the connected BLE device. It could be that this is the wakeup that you are seeing? (7.5 ms is the minimum time frame though)

   

Try tracking the low-power mode with an LED instead of using the debugger to eliminate asynchronous peripheral-running being the problem.

[JiWa_1379161]

Hi E

   

I appreciate your help. Upon experimenting and be determined to understand what is going on, I realized the debugger was adding its own issues with interrupt and deep sleep. It seems there is a lot of documentation on various BLE details but nothing really defines how it all works within the Cypress products. Once again, from my own experimenting I realized the BLESS was waking up on its own due to the connection interval. It would wake up, do a quick check and go back to sleep. I isolated the problem to this by removing all peripherals and leaving just the BLE module. If I did not pair, the BLESS would go to deep sleep and stay there. If I connected, it would keep waking up. 

   

The next step is getting the lowest power out of the unit. When I have the radio unpaired and both BLESS and MCU in deep sleep, I was getting about 400uA. I was able to knock this down to 150-200uA by placing all unused pins to analog inputs and also by changing the SWD lines to GPIO. The only other hardware on board is a small EEPROM which is I2C. That is not 150uA. I tried disabling the I2C module but that didnt change the current. Looking at the data sheet for the module, it is not very detailed as to what to be expected and under what conditions. DO you know what typical current level should be with BLE module unpaired, MCU and BLE in deep sleep and no other peripherals running at 3V? Every manufacturer indicates theres ridiculous low currents but dont detail what is needed to reach them.

[Anonymous · Accepted solution]

Our board only has a CYBLE 022001-00 chip on it, but it should help with locating the difference at least:

   

We are getting between 1.5 and 1.6 uA with the BLE peripheral and CPU both in deep sleep. We have pins setup to fire interrupts upon button presses, but so far they don't draw current except when the button is active 🙂

   

Here's a document specifying the expected power draws for the different modes for the PSoC 4: http://www.cypress.com/file/140991/download  "Designing for Low Power Applications"

   

Here's a document that should help with lowering power draw/usage for battery-powered devices: http://www.cypress.com/file/121271/download

   

If you are getting 200 uA current draw, then either you have some clocks/peripherals on that are drawing power (IMO,ILO,ECO,WCO, but you only need one to run the interrupt/wakeup clock iirc), or you have some passive elements that are drawing power.

[AnjanaM_61]

Hi ,

   

You are correct that the device will wake up at end of each connection interval and will goes back to sleep if no activities.

   

As E.Pratt suggested, please go through our low power appnotes for more details.

   

You can also refer the example codes along with the appnote from the site:

   

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

   

http://www.cypress.com/documentation/application-notes/an86233-psoc-4-low-power-modes-and-power-redu...

   

Thanks,
Anjana

   

Thanks,
Anjana