Root causes of high deep sleep current


  • administrators

    Dear All,

    We have now completed a series of extensive tests around the deep sleep issues being experienced with the WiPy 2.0, LoPy 1.0 and SiPy 1.0. We appreciate your patience whilst we were able to review in detail the root cause of this issue with the Espressif teams. Our findings are as follow:

    Root cause 1:
    The DC-DC switching regulator always stays in high performance PWM mode. We are using a pin from the ESP32 to control the operating mode of the switching regulator. In high performance PWM mode it offers the lowest output ripple and noise, but the quiescent current is ~10mA. When the regulator is set into ECO mode, the quiescent current goes down to 10uA. We chose this type of design in order to have the best performance and lowest ripple during active operation while being able to switch to ECO mode while in deep sleep. Unfortunately, the pin used to control this mode is out of the RTC domain, and therefore not usable during deep sleep. This causes the regulator to always stay in PWM mode, keeping it’s quiescent current at 10mA.

    Workaround:
    Power the board via the 3V3 pin using a stable 3V3 supply that is able to deliver at least 400mA. This lowers the deep-sleep current to around 2.5mA.

    Root Cause 2:
    The flash chip doesn’t enter power down mode because the CS pin is floating during deep sleep. This causes the flash chip to consume around 2mA of current. The way our circuit is designed, the VDD_SDIO domain of the ESP32 (which also powers the external flash), is powered externally instead of using the internal regulator in the ESP32 itself. Because of this, the flash memory always remains powered and never goes to deep sleep. We opted for this design as it had the benefit of being able to control the VDD_SDIO without having to rely on the value of the MTDI pin during boot-up. With this approach we gain 1 extra GPIO pin.

    Workaround:
    We have designed a retrofit hardware solution for this, and will very soon be releasing a deep-sleep shield that can be fitted between our expansion board and the modules (but also can be used without the expansion board). This deep sleep board will take care of powering down the module completely when the deep sleep command is sent. It’ll be able to wake on timer and pin interrupts. With the Low power shield the current consumption during deep sleep is between 7uA and 10uA depending on the wake sources configured. This board will work in a transparent way in terms of software. Once it is connected to the module it will be detected during start-up. The deep-sleep shield will resolve root causes 1 and 2.

    Conclusion:
    The design problems that have been identified only affect WiPy 2.0, LoPy 1.0 and SiPy 1.0. These design problems do not exist in any of the other Pycom developer boards such as FiPy, GPy or any of the OEM modules. You can see some of the test results from Daniel here: https://www.pycom.io/news/l01-oem-module-deep-sleep-test/. We will redesign the WiPy 2.0, LoPy 1.0 and SiPy 1.0 over the next few months in order to remove this deep sleep issue whilst enhancing the product performance to include 4MBytes of RAM and 8 Mbytes of flash.

    The FiPy, GPy and newer developer modules to be released (as well as the motherboard reference design for the OEM modules), have the switching regulator configured in automatic mode, therefore, when the module is active, the voltage regulation uses PWM mode for best performance and low ripple voltage, and when the current consumption drops to uA levels, it enters ECO mode consuming just 10uA. All the new designs with the 4MByte external RAM also use 1.8V for the VDD_SDIO supply, which comes from one of the ESP32 pins. With this approach, the flash and the external RAM are switched off during deep sleep, as well as any other additional circuits (LoRa, Sigfox, etc), ensuring the lowest possible current during deep sleep.

    Resolution:
    Pycom is committed to resolving this problem for our developer community and has been working in parallel on the development of the deep sleep shield in the shortest possible time.

    Whilst we are satisfied that this problem is limited to the first generation of the modules, this is of no consolation to those of you facing deadlines and whom require testing of the Ultra Low Power modes prior to moving to OEM modules. We believe the deep sleep shield will provide the ‘best’ resolution for this issue and will be making it available Free Of Charge to all customers whom have purchased the affected developer boards. To receive your free shield please email https://www.surveymonkey.co.uk/r/PSTPWBB order number, the number of shields required (maximum 1 per developer board purchased) and the delivery address. We expect to have all shields available for shipping Mid May 2017 (4 weeks time).

    Finally, moving forward, we will be bundling Free of Charge the deep sleep shield for customers whom purchase current stocks of the developer boards impacted thus removing any possible issue for our customers.

    Please note: For customers using Pysense and Pytrack, these boards are designed to support deep sleep mode (out-of-the-box) in the same manner as the deep sleep shield. We will also be releasing during the next few months a new expansion board V3 which supports the deep sleep feature and therefore can be used with the current batch of Pycom developer boards (LoPy 1.0, SiPy 1.0 and WiPy 2.0).

    On behalf of the entire team here at Pycom, thank you for your continued support!

    Best wishes
    Fred



  • Hi!
    The PIC10F322 needs programming? If yes, where can I find the code?
    Thank you!



  • @Fred - Is it possible to acknowledge receipt of the request for a shield when it is initially made and then notify us when it is dispatched, as at the moment I have no idea whether my submission was successful, or when I am likely to receive the shields ?!


  • administrators

    Hello,

    We have received all the surveys filled up to now and everything is going OK. We are targeting mass production of the deep sleep shields in early July and ship shortly afterwards.

    Cheers,
    Daniel



  • I've filled the form at https://www.surveymonkey.co.uk/r/PSTPWBB (mid April) and still nothing - no email confirmation, order progress and no DS shields.

    @Fred said in Root causes of high deep sleep current:

    Dear All,
    A quick update on this topic to confirm we are currently testing the Pilot Run samples in Eindhoven. All going well and we expect to have shields to ship circa 2 to 3 weeks e.g. 5/6 June. (...)

    @Fred Any news?



  • I am also wondering what the process is if the Deep Sleep Shields don't arrive. I ordered them when the email went around for my order of LoPy's but never received anything ?



  • @bucknall Did the shields arrive?



  • @Fred

    I didn't received my Deep Sleep Shield , what is the process to check if my request has been registered, plan and hipped to me?

    best
    Luc


  • administrators

    Hello,

    In the meantime while we publish the official library later this week, here is a short version of it which can be used to enter deep sleep mode using the Pytrack/Pysense board and wakeup after a pre-defined number of seconds:

    from machine import I2C
    from machine import Pin
    import machine
    import time
    
    
    I2C_SLAVE_ADDR = const(8)    # This one seems to be an unpopular addresss
    LIS2HH12_I2C_ADDR = const(30)   # both Pysense and Pytrack have the accelerometer onboard
    
    CMD_PEEK = const(0x0)
    CMD_POKE = const(0x01)
    CMD_MAGIC = const(0x02)
    CMD_HW_VER = const(0x10)
    CMD_FW_VER = const(0x11)
    CMD_PROD_ID = const(0x12)
    CMD_SETUP_SLEEP = const(0x20)
    CMD_GO_SLEEP = const(0x21)
    CMD_BAUD_CHANGE = const(0x30)
    CMD_DFU = const(0x31)
    
    REG_CMD = const(0)
    REG_ADDRL = const(1)
    REG_ADDRH = const(2)
    REG_AND = const(3)
    REG_OR = const(4)
    REG_XOR = const(5)
    
    ANSELA_ADDR = const(0x18C)
    ANSELB_ADDR = const(0x18D)
    ANSELC_ADDR = const(0x18E)
    
    ADCON0_ADDR = const(0x9D)
    ADCON1_ADDR = const(0x9E)
    
    _ADCON0_CHS_POSN = const(0x02)
    _ADCON0_ADON_MASK = const(0x01)
    _ADCON1_ADCS_POSN = const(0x04)
    _ADCON0_GO_nDONE_MASK = const(0x02)
    
    ADRESL_ADDR = const(0x09B)
    ADRESH_ADDR = const(0x09C)
    
    PORTC_ADDR = const(0x00E)
    
    WPUA_ADDR = const(0x20C)
    
    MEMORY_BANK_ADDR = const(0x620)
    
    class Pysense:
    
        def __init__(self, i2c=None, sda='P22', scl='P21'):
            if i2c is not None:
                self.i2c = i2c
            else:
                self.i2c = I2C(0, mode=I2C.MASTER, pins=(sda, scl))
            self.reg = bytearray(6)
            scan_r = self.i2c.scan()
            if not scan_r or LIS2HH12_I2C_ADDR not in scan_r or not I2C_SLAVE_ADDR in scan_r:
                raise Exception('Pysense board not detected')
    
        def _write(self, data, wait=True):
            self.i2c.writeto(I2C_SLAVE_ADDR, data)
            if wait:
                self._wait()
    
        def _read(self, size):
            return self.i2c.readfrom(I2C_SLAVE_ADDR, size + 1)[1:(size + 1)]
    
        def _wait(self):
            time.sleep_us(100)
            while self.i2c.readfrom(I2C_SLAVE_ADDR, 1)[0] != 0xFF:
                time.sleep_us(100)
    
        def _send_cmd(self, cmd):
            self._write(bytes([cmd]))
    
        def setup_sleep(self, time_s):
            self._write(bytes([CMD_SETUP_SLEEP, time_s & 0xFF, (time_s >> 8) & 0xFF, (time_s >> 16) & 0xFF]))
    
        def go_to_sleep(self):
            self._write(bytes([CMD_GO_SLEEP]), wait=False)
            # kill the run pin
            Pin('P3', mode=Pin.OUT, value=0)
    

    Example usage:

    from pysense import Pysense
    py = Pysense()
    py.setup_sleep(5)   # setup a 5 seconds sleep time
    py.go_to_sleep()
    

    This works for both Pysense and Pytrack.

    Cheers,
    Daniel


  • administrators

    @mcook, entering deepsleep using the Pytrack as the controller of the operation requires a different approach. We have a library for this that will be published in a few days this week. This library also allows to performing several different operations on the PIC microcontroller that's on the Pytrack/Pysense like reading the battery voltage.

    Cheers,
    Daniel



  • @Fred

    Hi,

    I received my PyTrack boards today. I have attached my LoPy to one of them. I am powering the PyTrack via USB. The USB is plugged into a USB multimeter. With the WiFi on, I see it is drawing about 125 mA at 5 VDC. After entering deep sleep, I see the current is reduced to ~48 mA. Is there some configuration that needs to be done in the code in order for the PyTrack boards to work properly with Deep Sleep?

    Mike



  • Is the script for the PIC also somewhere available?


  • administrators

    @_peter Yes, this is possible. The footprint of the board is slightly wider than the LoPy but the functionality and pinout is identical to that of the LoPy. This is can be used as an exact replacement for the LoPy!



  • @bucknall I designed the board for Lopy and thought of replacing it with the oem expansion board + oem module. According to you is it possible?


  • administrators

    @_peter If you're using a LoPy (Development Kit), you can currently get deep sleep with a Pytrack or Pysense - without these you'll need to wait until the Deep Sleep Sheild arrives



  • @bucknall Thank you, we are waiting for the shields.



  • @danielm I have to deliver a LoRaWan sensor node within about 15 days giving me the chance to deep-sleep for 10 minutes and that when it wake up do not join again. is possible ?


  • administrators

    @danielm The Deep Sleep Shields should be arriving in the 3rd week of June. We will ship them as soon as we receive them. Thanks for your patience!


  • administrators

    @_peter the OEM reference board does have the same LoPy pin out, with the only difference that P12 is also used there to drive the RF switch (you can see that on the schematics).



  • @bucknall
    When are you planning to ship deep sleep shields to your customers?


Log in to reply
 

Looks like your connection to Pycom Forum was lost, please wait while we try to reconnect.