Excess current draw after deepsleep



  • I'm running ver 1.20.1.r1 on a gpy with adhoc wifi disabled (pycom.wifi_on_boot(0)) which gives me a standyby current (no program running) of about 50mA. However after I run a program that terminates with a machine.deepsleep(20000) via Atom the standby current is 50mA for ~3s after wakeup then jumps to ~204mA where it stays. If I press the rest button it repowers @ 204mA for about 5s then drops back to 50mA where it stays. A soft reset (ctrlD) has no effect (current draw still 204mA).

    I can't figure out what is drawing the extra 154mA, why deepsleep causes it or why a hard reset fixes it but a soft reset doesn't. Anybody got some thoughts? This is really bugging me because I thought I had deepsleep sorted like a year ago & now it's doing weird stuff again.



  • @dgerman If I press reset then run

    import time, network, machine; print()
    #lte=network.LTE(); lte.deinit()
    causes={0:'pwrup', 1:'hardreset', 2:'wdt', 3:'wakeup', 4:'softreset', 5:'brownout'}; cause=causes[machine.reset_cause()]
    print(' powerup cause is', cause, ' check current', end=' ')
    for i in range(10): print(i, end=' '), time .sleep(1)
    t=10; print(' deepsleep(s)', t); machine.deepsleep(t*1000)
    

    the program deepsleeps at ~50uA after the first pass

    powerup cause is pwrup  check current 0 1 2 3 4 5 6 7 8 9  deepsleep(s) 10
    

    but ~170mA subsequently.

    powerup cause is wakeup  check current 0 1 2 3 4 5 6 7 8 9  deepsleep(s) 10
    

    To get the 50uA on all deepsleeps I have to uncomment line 2. My take on this is that a pwrup prevents 'smart provisioning' powering up the lte modem but wakeup from deepsleep does not. I'm unfamiliar with '.enable_pullups' & I'm not using it.



  • @kjm What do you mean "first cycle of the program"? Is the deepsleep expiring? This should cause the Gpy to reset (i.e. start a "first cycle").
    Did you .enable_pullups?
    What does deepsleep.get_wake_status() return?
    The 154mA seems suspiciously like the LTE radio is back on.
    Can you post more(all) code?



  • I figured it out! So called 'Smart provisioning' was turning the lte modem on after a deepsleep. A hard reset disables 'smart provisioning' apparently. So even if you're not using the gpy lte modem you need to switch it off (lte=LTE(); lte.deinit()) manually if you want low current deepsleep.

    I feel that this is contrary to https://docs.pycom.io/firmwareapi/pycom/machine/ which says of deepsleep, 'Execution is resumed from the main script, just like when pressing the reset button'. Fact is 'smart provisioning' powers up the lte modem after every deepsleep.



  • Further to my deepsleep woes on the gpy. I got another gpy, reflashed it with 1.20.1.r1 then ran

    import machine
    t=15; print(t, 's sleep'); machine.deepsleep(t*1000)
    
    

    What I'm finding is that deepsleep only drops the gpy to low current (~50uA) on the first cycle of the program. On subsequent cycles the program 'sleeps' but the current is ~204mA. Low current deepsleep works only if I press the reset button after each cycle of the program. Any thoughts on why low current deepsleep is a 'one shot' only?

    My feeling is that some process that draws an extra (204-50=154mA) kicks in after the first low current deepsleep & stays till I press the reset button. Any suggestions what it might be?


Log in to reply
 

Pycom on Twitter