3 Replies Latest reply on Apr 11, 2018 10:59 PM by ssl.huynh_3143771

    Checking BLE stack before going to Deep Sleep

    ssl.huynh_3143771

      Hi there,

       

      We are wondering if it's necessary to check that the BLE stack is on before going to Deep Sleep?

       

      We see in example projects:

      if(Cy_BLE_GetState() == CY_BLE_STATE_ON)

      {

          Cy_SysPm_DeepSleep(CY_SYSPM_WAIT_FOR_INTERRUPT);

      }

       

      We have tested for both cases with and without the if-statement which returns the same result:

      (1) While ble is not advertising and no device connected, the system always fails to enter deep sleep (always returns failure)

      (2) While ble is advertising, the system enters deep sleep every second deep sleep attempt/call (returns failure then success)

      (3) While device connected, the system always succeeds to enter deep sleep

      (4) After device disconnection/advertisement timeout, the system always fails to enter deep sleep until advertisement restarts

       

      We are curious the reasoning for checking the BLE stack before entering deep sleep and why the system isn't able to go to deep sleep in cases (1) and (4) as described above. What is also happening internally after device disconnection/advertisement timeout, because we notice there is a time frame where the system doesn't attempt to enter deep sleep (though we have the deep sleep API called in a while loop) and then the system always fails to deep sleep thereon after.

       

      Best,

      Steve

        • 1. Re: Checking BLE stack before going to Deep Sleep
          hima

          In case of BLE implemented on single core the BLE interrupts can wake the device from deep sleep. Can you point me to the exact example project?

          In case you have implemented BLE on dual core please refer to the KBA: Setting Cores to Deep Sleep Mode while BLE Function is Enabled on PSoC® 6 – KBA223291

           

          Thanks,

          Hima

          • 2. Re: Checking BLE stack before going to Deep Sleep
            ssl.huynh_3143771

            We were referring to the example project AN219528 - PSoC(R) 6 MCU Low-Power Modes and Power Reduction Techniques which uses dual cores. But we are only implementing with single core and weren't sure if there were differences between deep sleep using single and dual core. However the link you provided answers a lot of our questions.

             

            But we're still unsure why the behavior described in (1) is occurring still. In case (1), the bless interrupt is never triggering when ble is not advertising/connected so we are thinking the system should still be able to successfully enter deep sleep. However after we restart advertisement by a switch press, the system can enter deep sleep successfully again.

             

            Thanks,

            Steve

            • 3. Re: Checking BLE stack before going to Deep Sleep
              ssl.huynh_3143771

              We've fixed the issue described in (1). In turns out because we were only calling Cy_BLE_ProcessEvents() in a callback function attached to the bless interrupt, the API was never getting called because the bless interrupt doesn't trigger if bluetooth is not advertising and no device is connected. It turns out Cy_BLE_ProcessEvents() should still be called even if there is no advertisement/device connection.

               

              That leads to our follow up question: is there another internal interrupt beside the bless interrupt? We notice that when bluetooth is not advertising and no device is connected, the system successfully goes to sleep. However, after a little while it wakes up and requires API call of Cy_BLE_ProcessEvents() before it can successfully return to sleep. We know it's not the bless interrupt waking up the system since we've registered a callback function to the bless interrupt and that function does not get called.

               

              We've attached the code that we are currently testing if it helps to get a better context of what we've described above. Exclude and include line 102 where we've commented "Here" to see the different results printed out in UART. On exclusion, the system successfully goes into deep sleep initially but fails thereon after.

               

              Best,

              Steve