Deepsleep bug fipy

[robert-hh]

@Jaap-Crezee said in Deepsleep bug fipy:

However, I am hugely unsatisfied with this; this is actually a (very) old FiPy that does not support the T-Mobile NB-Iot channel of today.

Pycom had a program to replace old Fipy boards, which do not support extended bands. Maybe this program is still active. See this post: https://forum.pycom.io/topic/3843/important-news-regarding-cat-m1-and-nb-iot-cellular-range

[Jaap Crezee]

@robert-hh Hi and thank you; that link doesn't work anymore. So I still figured I could put this module to good use as lora sensor module.
@Gijs As I feared, deepsleep does not work for a consecutive time.
The first time the current drawn from the battery reaches 0.01A on 5V (which is acceptable for now); on the second deepsleep it remains 0.19A which is way, way too high.
What is causing this and how to work around it?

[Jaap Crezee]

I will answer my own question :):

This workaround prevents the panic from happening as well (even with lte_en_on_boot(False)):

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2128
load:0x4009fa00,len:19760
entry 0x400a05bc
Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; FiPy with ESP32
Type "help()" for more information.
>>> from network import LTE
>>> lte = LTE()
>>> lte.deinit()
>>> import machine
>>> machine.deepsleep(5000)
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2128
load:0x4009fa00,len:19760
entry 0x400a05bc
Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; FiPy with ESP32
Type "help()" for more information.
>>> from network import LTE
>>> lte = LTE()
>>> lte.deinit()
>>> import machine
>>> machine.deepsleep(5000)
ets Jun  8 2016 00:22:57

rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff8020,len:8
load:0x3fff8028,len:2128
load:0x4009fa00,len:19760
entry 0x400a05bc
Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; FiPy with ESP32
Type "help()" for more information.
>>> rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
>configsip: 0, SPIWP:0xee
>clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
>mode:DIO, clock div:1
>load:0x3fff8020,len:8
>load:0x3fff8028,len:2128
>load:0x4009fa00,len:19760
>entry 0x400a05bc
>Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; FiPy with ESP32
>Type "help()" for more information.
>>>> import pycom
>>>> pycom.lte_modem_en_on_boot()
>False
>>>> from network import LTE
>>>> lte = LTE()
>>>> lte.deinit()
>>>> import machine
>>>> machine.deepsleep(5000)
>ets Jun  8 2016 00:22:57
>
>rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
>configsip: 0, SPIWP:0xee
>clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
>mode:DIO, clock div:1
>load:0x3fff8020,len:8
>load:0x3fff8028,len:2128
>load:0x4009fa00,len:19760
>entry 0x400a05bc
>Pycom MicroPython 1.20.2.r2 [v1.11-3a7776d] on 2020-11-23; FiPy with ESP32
>Type "help()" for more information.
>>>> 
>

But ... there is a stupid catch:

lte = LTE()    # takes almost 5 seconds

lte.deinit()    # takes almost 5 seconds

Which means the device is wasting 10 seconds of valuable battery life.

Can this issue be fixed properly ASAP? These kind of bugs (including the network stability on the POE ethernet module on the Pygate) make me believe the Pycom products are only for hobby projects....

[robert-hh]

@robert-hh I opened that forum link before I sent my reply. So the forum entry is still there. The embedded link to a form migth be gone. But you can always write to support@pycom.io for you request.

[Avathar]

Hi!

I ran into the same or a similar bug yesterday, using firmware 1.20.1.r1 (since newer firmware has the rtc time problem stated in another thread).

I have a board with various sensors and an adafruit feather m0, which manages the sensor readings.
For communication i have a rather new FiPy, which is also connected to a DS3231 RTC and a Quectel L86 GPS.

The FiPy normally wakes up every hour or, in case of emergency, is woken up by the feather module via Pin P16.

I've also tested this with a pysense board, so the next readings apply to a FiPy with pysense board attached.

The first time after a reset, the FiPy runs and the power consumption is about 130-180mA. Afterwards it goes to deepsleep via machine.deepsleep() and the power consumption drops to about 13mA at 5V. However, after the FiPy is woken up, either by the internal rtc or by the wakeup pin, the system uses a lot more power (about 100-150 mA more, totally 280mA) and after going back to deep sleep, the power consumption stays also higher at about 150mA.

When disabling LTE, the system properly goes to sleep and uses 13mA, but after waking up it seems the lte modem is enabled again, even with lte_modem_on_boot = false, so the first thing i could do is disabling the LTE modem, but as stated below this takes several seconds and is a waste of time and power.

So it would be a good idea to leave the lte modem disabled, even when coming out of deep sleep.

[tuftec]

Hmmm.
There seems to be a few little issues with the later versions of Pycom firmware.
I have found also that the Little FS gives problems also under some circumstances.

[Jaap Crezee]

@Gijs I just tested firmware https://github.com/pycom/pycom-micropython-sigfox/releases/tag/v1.20.2.r3
This seems to fix the problem with the deep sleep crash, but it seems fixed in a VERY BAD way. Now every time the module boots, I see this (regardless of me turning it to False again):

>>> pycom.lte_modem_en_on_boot()
True

Also, the current consumption stays way too high after each subsequent deepsleep, 0.15A. Updated this issue on GitHub: https://github.com/pycom/pycom-micropython-sigfox/issues/412
Sometimes even the initial deepsleep (after POR) will trigger 0.15A now!

[tuftec]

I am still having issues with the lte modem with 1.20.2.r3. However, I believe my problems are related to some sort of power related issue. When my code is running off batter, it seems to work fine, but when being charged, via solar, the sequans modem appears to loose its way. Yet the power rails look clean in both instances.

Having a high cureent draw when the modem is supposed to be powered down is a bit of an issue in extremely low power applications. This needs to be investigated further and fixed.

Peter.

[Gijs]

Thanks for informing me, I'll highlight it again with the FW team (I think our peter is already aware of this)

[peterp]

Ok, it seems a couple different issues are making the rounds here. Let me try to pull it apart:

@Avathar said in Deepsleep bug fipy:

When disabling LTE, the system properly goes to sleep and uses 13mA, but after waking up it seems the lte modem is enabled again, even with lte_modem_on_boot = false, so the first thing i could do is disabling the LTE modem, but as stated below this takes several seconds and is a waste of time and power.
So it would be a good idea to leave the lte modem disabled, even when coming out of deep sleep.

Yes, there seems to be an issue where sometimes on boot up, the LTE modem gets powered up resulting in higher power consumption during active time and during deepsleep. This is a problem and indeed the best know workaround seems to be to deliberately initialise and then deinit LTE.

@Jaap-Crezee said in Deepsleep bug fipy:

@Gijs I just tested firmware https://github.com/pycom/pycom-micropython-sigfox/releases/tag/v1.20.2.r3
This seems to fix the problem with the deep sleep crash, but it seems fixed in a VERY BAD way. Now every time the module boots, I see this (regardless of me turning it to False again):

>>> pycom.lte_modem_en_on_boot()
True

That's certainly not the idea behind the fix https://github.com/pycom/Firmware-Development/commit/358085bda144a97d48a9dd6deccb2fe6eb3a91b7

Also, I am not able to reproduce this. Are any of the other "on_boot" flags "stuck" in a similar way?

print(pycom.heartbeat_on_boot())
        print(pycom.lte_modem_en_on_boot())
        print(pycom.pybytes_on_boot())
        print(pycom.smart_config_on_boot())
        print(pycom.wdt_on_boot())
        print(pycom.wifi_on_boot())

Edit: Can you still reproduce the problem when you erase nvram with the installer?

Also, the current consumption stays way too high after each subsequent deepsleep, 0.15A. Updated this issue on GitHub: https://github.com/pycom/pycom-micropython-sigfox/issues/412

That issue is about a Lopy-4, which doesn't have a LTE modem. So, I am very sure #412 is not the same issue as the one about LTE mentioned above. Which module are you using?

@tuftec said in Deepsleep bug fipy:

When my code is running off batter, it seems to work fine, but when being charged, via solar, the sequans modem appears to loose its way. Yet the power rails look clean in both instances.

Can you add more details? What does "loose its way" mean? How do you determine that the power rail looks clean? In some power measurements with an Otii Arc I've seen very short, high peaks in current draw. From memory, I think it was something like 200mA at 3.75V, no battery attached. How much does your solar panel supply?

[Jaap Crezee]

@peterp said in Deepsleep bug fipy:

Ok, it seems a couple different issues are making the rounds here. Let me try to pull it apart:

Hi Peter, thank you.

Yes, there seems to be an issue where sometimes on boot up, the LTE modem gets powered up resulting in higher power consumption during active time and during deepsleep. This is a problem and indeed the best know workaround seems to be to deliberately initialise and then deinit LTE.

I think we want to investigate why the LTE modem gets powered up, even when the configuration was programmed with power_on(False)

That's certainly not the idea behind the fix https://github.com/pycom/Firmware-Development/commit/358085bda144a97d48a9dd6deccb2fe6eb3a91b7

Okay, agree saw this commit and this change is doing something else; good to know. PS Your link is incorrect, should be: https://github.com/pycom/pycom-micropython-sigfox/commit/358085bda144a97d48a9dd6deccb2fe6eb3a91b7 ?

Also, I am not able to reproduce this. Are any of the other "on_boot" flags "stuck" in a similar way?

print(pycom.heartbeat_on_boot())
        print(pycom.lte_modem_en_on_boot())
        print(pycom.pybytes_on_boot())
        print(pycom.smart_config_on_boot())
        print(pycom.wdt_on_boot())
        print(pycom.wifi_on_boot())

Edit: Can you still reproduce the problem when you erase nvram with the installer?

I cleared the nvram using pycom.nvs_erase_all(); should that result into the same functional behaviour as the installer/fw updater clear nvram tickbox?

Also, the current consumption stays way too high after each subsequent deepsleep, 0.15A. Updated this issue on GitHub: https://github.com/pycom/pycom-micropython-sigfox/issues/412
That issue is about a Lopy-4, which doesn't have a LTE modem. So, I am very sure #412 is not the same issue as the one about LTE mentioned above. Which module are you using?

True; I have been using both a LoPy4 and WiPy (version 1.0 and ~1.1~ edit: 1.2). With the LoPy4 I am not seeing this deepsleep current/usage problem, but with the WiPy I do. There was no other issue active so I posted it here. I could make a new one?

I'll try to experiment with clearing and the new firmware yet again on both WiPy boards.

[Jaap Crezee]

@peterp

I just updated another FiPy 1.2 to
Pycom MicroPython 1.20.2.r3 [v1.11-044dfea] on 2020-12-23; FiPy with ESP32
I also ticked the boxes format and clear config + NVRAM.

So the device is now clear. Some more background:

>>> import pycom
>>> print(pycom.heartbeat_on_boot())
False
>>> print(pycom.lte_modem_en_on_boot())
False
>>> print(pycom.pybytes_on_boot())
False
>>> print(pycom.smart_config_on_boot())
False
>>> print(pycom.wdt_on_boot())
False
>>> print(pycom.wifi_on_boot())
False
>>> 

When booting, I measure a current of about 60mA. See my setup:

When going to deepsleep, this drops down to 30mA. I think this is way too high. With a LoPy4 or WiPy this drops to about 0.00A which means I cannot measure it with this setup (= okay).

With a GPy with the setup above after fw-update + clear deepsleep() gives me about 0.00-0.01A