Excess current draw after deepsleep

[kjm]

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.

[kjm]

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?

[kjm]

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.

[dgerman]

@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?

[kjm]

@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.