1 Reply Latest reply on Mar 26, 2017 4:13 AM by bmah

    DeepSleep / Watchdog timing problems when using BLE

    artur2000_2263466

      Hi,

         

      I try to implement the following scenario:

      boots -> process a task in ACTIVE mode for exectly 2 sec -> deep sleep for 5 sec -> task for 2 sec -> deep sleep 5 sec and so on.

         

      This works great with WDT (wakeup from deep sleep after counting WDT intervals until 5 sec are reached) and a one shot timer (to time the 2 sec task duration).
      But if I add BLE functionality into the design, something does not fit any more. I invested already two days into it, and read of course all the available PDFs (BLE getting started + Low-Power Modes and Power Reduction Techniques) , I analised the LPM example project but it uses the WDT differently then me.

         

      I prepared a use case project (with oth) to analyse the problem, which uses LEDs and UART for logging.

      So without BLE, where everything is fine, the following expected LED sequence can be observed:

         
          

      GREEN (task) for 2 sec
      BLUE (deep sleep) for 5 sec 
      during BLUE phase above 4 WHITE flashes every 1 sec (WDT interval ticks, reentering deep sleep)
      end of BLUE phase above 1 WHITE double flash (wake up from deep sleep)

      and so on...

         
         

      UART logs the following sequence, (the single point after each WDT tick stays for reentering deep sleep mode).

         
          

      Do something...
      Try to sleep...

          

      WDT tick: 1
      .
      WDT tick: 2
      .
      WDT tick: 3
      .
      WDT tick: 4
      .
      WDT wakeup

         
         

       Now if I enable BLE (un-comment #define ENABLE_BLE in main.h), I observe the following pattern

         
          

      GREEN for 2 sec
      GREEN for 2 sec
      BLUE flickering for about 3 sec
      during BLUE phase above 2 WHITE flashes every 1 sec (WDT interval ticks, reentering deep sleep)
      end of BLUE phase above 1 WHITE double flash (wake up from deep sleep)

          

      and so on...

         
         

      UART logs the following sequence

         
          

      Do something...
      Try to sleep...
      Update GATT database...
      Do something...
      Try to sleep...

          

      WDT tick: 2
      ....................................................
      WDT tick: 3
      ..............................................................................
      WDT tick: 4
      .............................................................................
      WDT wakeup

         
         

      One can see many single points between WDT ticks, so the program tries reentering deep sleep very often but stays there only for a short time. I suppose it is because of the BLE subsystems interrupts, which would be fine if the average power savings were OK which I did not measure now. Am I correct with this assumption? How can I tune the intervals here, I did not catch this in the docs.
      But what really bothers me is the fact, that work phase (GREEN) occurs twice without any sleep phase between, and that the deep sleep phase itself is shorter as expected (something above 2 sec instead of 5).
      Eventually the program crashes after some time sooner or later. I am not experienced enough yet to debug this :-)

      Why does BLE interfere with the WDT timer so radically? I would expect, that the WDT does it work in background without any distortions using LFCLK. Giving WDT higher interrupt priority than BLESS or changing the LFCLK source from WCO to ILO does not make any difference in the pattern.

      Is there anything I can do to fix my design? I will appreciate any optimizations.
      What can I do to better understand the BLE low power behavior?

      My project is attached to this post.

      Thx

         

       

         

      Edit: I found a logical error, now the timings are OK but the connection from a GAP client (CySmart app) can not be established reliably, especially during sleep phase. I would say this is my actual problem now + the random crashes after long running times.