FW 1.18.0 - increased boot time / power consumption?



  • I noticed that boot of frozen application on FW 1.18.0 takes longer so I did some comparison. Frozen application is exactly the same in both builds. Property wifi_on_boot is set to False during initial boot after flashing and I verified that it is set to False before the tests were performed.

    FW 1.14.0.b1 - execution time ~1.15s, energy consumed during active cycle ~59uWh
    0_1528984331557_SW_0.9.6_on_FW_1.14.0.b1.png

    FW 1.18.0 - execution time ~1.94s, energy consumed during active cycle ~148uWh
    0_1528984405374_SW_0.9.6_on_FW_1.18.0.png

    Also peak current during LoRa transmission in the end of active cycle seems to be higher in case of FW 1.18.0 (~175mA vs ~107mA).

    There is also suspicious spike in the second half of active cycle reaching 284mA. I believe after this moment the (pre-compiled) Python code gets executed.

    What can be causing this behavior? Is WiFi radio really disabled during boot?



  • @catalin
    I finally managed to perform tests of releases between 1.14.0.b1 and 1.18.0.b1.

    Otii ARK traces are available here:
    https://drive.google.com/open?id=1kIZL0HJHn_dEIPDM_jv6fEhDhb_Ukfqj

    Significant execution time increase occured between versions:
    1.17.0.b1:
    MP: d0dc708a0197d2900a5620648725794a1fb5c8f3
    IDF: 3b54cd7473aefdb8b75531a21ce340c4bd2221da
    and
    1.17.2.b1:
    MP: 1bf377b08e2162e8534b6cbe78dcdeeb930f64b8
    IDF: 4eab4e1b0e47c73b858c6b29d357f3d30a69c074



  • @catalin
    I don't use make SECURE=on.
    I have only built 1.14.0 and 1.18.0 with the simple app mentioned above.
    During next week I will try to find time to to build releases in between and test them. If you manage to do that sooner it would be even better :)



  • hi @danielm, are you using features like Secure Boot and Flash Encryption, ie. make SECURE=on ?

    If you have testing setup prepared, could you take consecutive builds from 1.14 to 1.18? It would help us to spot the problem faster.



  • @sympatron
    No I did not. Daniel mentioned that it might have something to do with secure boot feature which was introduced in between tested releases.



  • To me it looks like it stays awake longer than before. The rest looks similar.

    Did you make any progress with this?



  • I did some more testing using very simple application built as frozen _main.py:

    import machine
    import pycom
    import os
    
    pycom.wifi_on_boot(False)
    print(os.uname())
    machine.deepsleep()
    

    Following Xtensa compiler was used for both builds:
    https://dl.espressif.com/dl/xtensa-esp32-elf-linux64-1.22.0-80-g6c4433a-5.2.0.tar.gz

    FW 1.14.0.b1 with last commit 5bb7bc2941919e35953e2dd47e77f5a11eefa82a was built with SDK with last commit be424097224394c29ec927d5f197e061c9ce8800.
    0_1529053446263_test_app_FW_1.14.0.b1.png

    FW 1.18.0 with last commit 4481a1c283be97640592ea2a0440830e336064de was built with SDK with last commit 4eab4e1b0e47c73b858c6b29d357f3d30a69c074.
    0_1529053455543_test_app_FW_1.18.0.png

    It's obvious that execution is significantly slower on 1.18.0. It literally takes away years of operation in case of battery powered sensors which are in deep-sleep most of the time.


Log in to reply
 

Pycom on Twitter