Welcome to the Pycom forum Forum
    • \[\[global:header.categories\]\]
    • \[\[global:header.recent\]\]
    • \[\[global:header.tags\]\]
    • \[\[global:header.popular\]\]
    • Login

    Explore Pybytes | Official Documentation | Report a Firmware Bug/Issue | GitHub

    Firmware Updates

    Scheduled Pinned Locked Moved LoPy
    lopyotaupdate
    8 Posts 3 Posters 3.4k Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      ssmith
      last edited by

      I see a fair amount of discussions and conflicting information about FW updates. I can update FW just fine using the expansion board and the Pycom Firmware Update. That works OK in a lab situation but OTA updates are critical for any type of real application.

      I see references to placing an appimg.bin file in the /flash/src directory via ftp in order to update the FW. It appears this no longer works? This seems like such a core function I can't imagine why it would be removed. Hopefully I'm just missing something.

      Without the ability to update the FW in the field, this product is not really viable. Is there a way to do this and if not is there a time frame for when it will work?

      I 1 Reply Last reply Reply Quote 1
      • I Offline
        Innocenzo @ssmith
        last edited by Innocenzo

        @ssmith I solve it writing some code that "emulate" FTP and download a new version of the files. But this solution is
        slow and inefficient since can update only File System and cannot update WiPy / LoPy Firmware

        1 Reply Last reply Reply Quote 0
        • J Offline
          jmarcelino
          last edited by jmarcelino

          OTA firmware updates actually do work with a very small tweak:

          https://github.com/pycom/pycom-micropython-sigfox/issues/5

          However I think they've not been properly enabled yet because the image size and bootloader may be changing too much at the moment (the updater code in particular expects some fixed locations).

          But let's see what the real experts say :-)

          I 2 Replies Last reply Reply Quote 4
          • I Offline
            Innocenzo @jmarcelino
            last edited by

            @jmarcelino Hi,
            As you suggest on GitHub, I follow this two guides in order to setup the build environment:

            • https://github.com/pycom/pycom-micropython-sigfox
            • https://github.com/pycom/pycom-micropython-sigfox/tree/master/esp32

            I have installed the xtensa compiler with no problem, but when try to launch the command
            $ make BOARD=WIPY -j5 TARGET=boot

            I have these errors:
            CC bootloader/bootmgr.c
            CC bootloader/mperror.c
            In file included from bootloader/mperror.c:18:0:
            /home/aeromechs/esp/esp-idf/components/esp32/include/heap_alloc_caps.h:2:2: error: #warning heap_alloc_caps.h has been renamed to esp_heap_alloc_caps.h. The old header file is deprecated and will be removed in v3.0. [-Werror=cpp]
            #warning heap_alloc_caps.h has been renamed to esp_heap_alloc_caps.h. The old header file is deprecated and will be removed in v3.0.
            ^
            In file included from bootloader/bootmgr.c:18:0:
            /home/aeromechs/esp/esp-idf/components/esp32/include/heap_alloc_caps.h:2:2: error: #warning heap_alloc_caps.h has been renamed to esp_heap_alloc_caps.h. The old header file is deprecated and will be removed in v3.0. [-Werror=cpp]
            #warning heap_alloc_caps.h has been renamed to esp_heap_alloc_caps.h. The old h
            ^
            cc1: all warnings being treated as errors
            cc1: all warnings being treated as errors
            ../py/mkrules.mk:47: set di istruzioni per l'obiettivo "build/WIPY/release/bootloader/bootmgr.o" non riuscito
            make: *** [build/WIPY/release/bootloader/bootmgr.o] Errore 1
            make: *** Attesa per i processi non terminati....
            ../py/mkrules.mk:47: set di istruzioni per l'obiettivo "build/WIPY/release/bootloader/mperror.o" non riuscito
            make: *** [build/WIPY/release/bootloader/mperror.o] Errore 1

            J 1 Reply Last reply Reply Quote 0
            • J Offline
              jmarcelino @Innocenzo
              last edited by jmarcelino

              @Innocenzo
              Are you using pycom-esp-idf from https://github.com/pycom/pycom-esp-idf.git ?

              It seems you're not as in your case the folder is just named esp-idf

              Make sure you have done all of these before building:

              git clone https://github.com/pycom/pycom-esp-idf.git
              cd pycom-esp-idf
              git submodule update --init
              export IDF_PATH=~/pycom-esp-idf
              
              I 1 Reply Last reply Reply Quote 1
              • I Offline
                Innocenzo @jmarcelino
                last edited by

                @jmarcelino Ok I follow this guide: http://esp-idf.readthedocs.io/en/latest/linux-setup.html.
                There are so many guides that I am confused.

                I download the esp-idf-template. After "make configmenu" and "make" I have these bin files:

                • app-template.bin
                • partitions_two_ota.bin
                • bootloader.bin
                • partitions_singleapp.bin

                I think that app-template.bin is the "appimage.bin" that I can use with FTP.

                But something is not clear. If I want my version of boot.py, my version of main.py and add some files in /flash/lib
                and create a bin to flash on WiPy.....How can I do that?
                Only this guide : https://github.com/pycom/pycom-micropython-sigfox/tree/master/esp32
                talk about frozen module, but It doesn't work.

                J 1 Reply Last reply Reply Quote 0
                • J Offline
                  jmarcelino @Innocenzo
                  last edited by jmarcelino

                  @Innocenzo
                  Well no, don't follow http://esp-idf.readthedocs.io/en/latest/linux-setup.html, just follow the 2 guides I linked to and do

                  make BOARD=WIPY -j5 TARGET=boot
                  make BOARD=WIPY -j5 TARGET=app
                  and finally
                  make BOARD=WIPY -j5 flash

                  in your pycom-micropython-sigfox/esp32 folder

                  and since you're talking about the LoPy change WIPY to LOPY.

                  Having your own main.py and boot.py is a completely different matter. The LoPy has some Flash organised into partitions, just like a hard drive. The firmware update process doesn't usually change those areas. You'd have to make changes to C code to generate those files on the fly - or just FTP into the LoPy and upload them after the flash is done!

                  Frozen modules is yet another topic and not related to boot.py/main.py.

                  1 Reply Last reply Reply Quote 0
                  • I Offline
                    Innocenzo @jmarcelino
                    last edited by Innocenzo

                    @jmarcelino Unfortunately, the procedure posted here https://github.com/pycom/pycom-micropython-sigfox/issues/5
                    doesn't work. I' ve followed these steps:

                    • Change bootloader (1536 -> 1024)
                    • make BOARD=WIPY TARGET=boot
                    • make BOARD=WIPY TARGET=app
                    • make BOARD=WIPY flash
                    • everything work and now with Filezilla I can upload file with size > 1MB
                    • After I create a new image edited the frozen file _boot.py with a print("Hello World")
                    • make BOARD=WIPY TARGET=boot
                    • make BOARD=WIPY TARGET=app
                    • with Filezilla I copy appimg.bin in /flash/sys/
                    • reset the board (with the physical button )
                    • firmware doesn't change

                    Instead if I execute: make BOARD=WIPY flash, the firmware changes.

                    So I think that "the updater task" doesn't start on reset.

                    EDIT: I notice that the file appimg.bin uploaded with Filezilla disappears immediately, before reset.

                    1 Reply Last reply Reply Quote 0

                    Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                    Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                    With your input, this post could be even better 💗

                    Register Login
                    • 1 / 1
                    • First post
                      Last post

                    Pycom on Twitter

                    Pycom