3 Replies Latest reply on Apr 27, 2015 4:30 AM by user_14586677

    DeepSleep power consumption with UART

    user_460425683

       Hello,

         

      I am having some issues with reducing power consumption on the PRoC 4 BLE chip.  Maybe someone can help me.

         

      If I create a new project on the chip, and only enter the following commands in main.c, the resulting current consumption will be 1.3uA as expected:

         

      int main() {

         

         CyDisableInts();
         CySysClkEcoStop();
         CySysPmDeepSleep();

         

         for (;;) { }

         

      }

         

       If I add an SBC UART configured for 9600 baud to TopDesign and make no changes to the code (I do not start the component), I am seeing a current consumption around 370 uA.

         

      I have tried placing a SBC_UART_1_Stop(); command prior to entering DeepSleep as well.  In all situations, it seems that if a UART is defined, the resulting power consumption cannot be reduced.  Any thoughts as to why that would be?

         

      In addition, the datasheet seems to indicate that the UART consumption should be 9uA at speeds of 100Kbits/sec (which 9600 baud is well under) and 312uA at speeds of 1000Kbits/sec.  When I add a UART configured at 9600 baud, I am seeing a much larger current consumption than 9uA.

         

      My current readings are taken at J15 on the evaluation kit.

         

      Thanks for any help folks can offer.

         

      - Chris

        • 1. Re: DeepSleep power consumption with UART
          user_460425683

          Hello again,

             

          I am having a conversation with myself, but I hope this information helps someone else.

             

          So interestingly I found that if I tie the UART RX or TX pins to ground, the current consumption drops to where I would like to see it, 1.3uA.  Which seems to indicate that possibly an interrupt is being triggered on the floatiness of the UART pins.  I can probably work with this by ensuring those pins do not float.

             

          The odd thing is, that I do not have the box checked labeled "Enable wake from Deep Sleep Mode".  So in my opinion if those pins or floating or not, nothing really should be happening as long as that box is not checked.  Does that check box work on the PRoC 4 BLE chip?

             

          - Chris

          • 2. Re: DeepSleep power consumption with UART
            user_460425683

            Some further testing seems to indicate that any pin tied to an interrupt, will continue to be serviced to some extent  in DeepSleep mode even if that interrupt is disabled.  Others may already know this, but it is news to me.  So please be mindful of floating pins that are tied to an interrupt or any digital component.  If they will waste power.

               

            Setting them to resistive pull down or resistive pull up (which ever is appropriate) appears to correct the problem.

            • 3. Re: DeepSleep power consumption with UART
              user_14586677

              A digital input left floating will potentially draw a lot of power.

                 

               

                 

              This ap note discusses GPIO and other considerations when

                 

              sleep modes are used and issues associated with measuring

                 

              power while debugging.

                 

               

                 

                  

                 

                       

                 

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

                 

               

                 

                  

                 

                        

                 

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

                 

               

                 

               

                 

               

                 

              Regards, Dana.