OTA or not OTA that is the question...

[jcaron]

@Paco88 May I ask why you would need to do that?

If you want to read the contents of the flash you can use esptool.py with command read_flash though I'm not sure you can get exactly the same data as the appimg.bin.

[Paco88]

@robert-hh said in OTA or not OTA that is the question...:

And if you need it for a different purpose on a WiPy node, you can attach a SD card and store a copy there.

I'm developing a commercial custom device using wipy oem.
I need a way to update the product with newer FW version.
Something like the OS update of smartphone and pc.

[robert-hh]

@Paco88 So you're aiming at a device updating itself?

[Paco88]

@robert-hh
Yes. But i'm having problem with the download of apimg.bin from the wipy.

[robert-hh]

@Paco88 Sorry Sir. Please explain more detailed what you want to achieve and what you tried to get here.
The FAT file system of a standard WiPy is too small to hold the file appimg.bin. If you want to store appimg.bin in the file system, you have to extend it, e.g. by adding a SD card. And still, at the moment you cannot install that file as a new firmware. One could try to implement a similar mechanism as is used for OTA: if an attempt is made to store a file at /flash/sys, it is accepted as a new firmware stream. But that is not there yet and tricky to implement.

[BetterAuto]

I had envisioned the devices self-updating by downloading the file to the local file system via a secure manner e.g. HTTPS or MQTT over TLS then copying that via an FTP client Py script to its own internal FTP server for final install. If you're saying the internal file system is too small I could see using the SD card or perhaps even an external I2C flash memory.

Is this feasible?

[robert-hh]

@BetterAuto If you can have a ftp client connect to the local server, then it should be possible. A small ftp client was provided by spotlightkid here: https://github.com/SpotlightKid/micropython-ftplib

[robert-hh]

@betterauto Actually I gave it a try. The ftp client is working, when I connect to a different device. But I could not get a connection to itself.
Unless there is another option, you could do that: If you have a cluster of devices, then one of them could act as an update server, which pulls the update from a remote hub and distributes that locally.

[BetterAuto]

What error did you get? Doesn't make sense it can't connect to itself, it's just another IP right?

[robert-hh]

This post is deleted!

[robert-hh]

@robert-hh By looking into the pycom module I found that an OTA interface for Python scripts already exists. There are three methods:
pycom.ota_start()
pycom.ota_write(data)
pycom.ota_finish()
So one can easily use them. Start the update by calling ota_start(). Then receive the image data in arbitrary chunks and call ota_write() with it. Once the data is transferred, call ota_finish().

[BetterAuto]

@robert-hh does that only update files or also the firmware? Where do I find more info on this?

[robert-hh]

@betterauto It ONLY updates the firmware. There is no documentation yet. I'll give it a try by using ftplib for downloading the file and let you know.

[robert-hh]

@betterauto OK. So here is my very simple sample script, using ftplib:

#
# OTA update using ftplib and the pycom.ota_* methods
#
from ftplib import *
from pycom import *

def do_write(data):
    ota_write(data)
    print(".", end="")

def ota():
    ftp = FTP("server_ip", 21, "user", "password")
    ota_start()
    ftp.retrbinary("RETR appimg.bin", do_write, 1024)
    ota_finish()
    
ota()

I added an intermediate call to do_write() to have an progress indication.
Obviously you can use ftplib to download other files as well.

[BetterAuto]

So this code uploads a bin file from the local file system to the local ftp server? Looks like the other way round.

Edit: Nevermind, I see you are fetching the file from an ftp server to flash it. Beautiful. I can do the same but fetch the file with MQTT over TLS to the local file system and flash itself in chunks.

I hope to try it soon. Nice find.

[robert-hh]

@betterauto You do not have to store the file in the local files system, if there is no space. You can feed the data into OTA on the fly while fetching.
I made a few attempts with:

• interrupting an update and then starting a new one.
• repeating the update w/o restart in between.

All was stable. Not a very exhaustive test, but at least a first check. Since the image itself carries a checksum & signature, which is checked at the call of ota_finish(), transmission errors should not harm.

[Paco88]

@robert-hh
Have you performed a full OTA write?

[robert-hh]

@paco88 Of course, several times. And I verified that the new image is then excuted, by embedding changing frozen bytecode.
The example below is simplified, in that I had to insert a gc.collect() into the do_write() function, epsecially with a larger buffer size.
I have sketched another example here, which uses a fixed preallocated buffer. And yes, I tested that variant too.

# Firmware update by reading the image from the SD card
#
from pycom import ota_start, ota_write, ota_finish
from os import mount
from machine import SD

BLOCKSIZE = const(4096)
APPIMG = "/sd/appimg.bin"

sd = SD()
mount(sd, '/sd')

with open(APPIMG, "rb") as f:
    buffer = bytearray(BLOCKSIZE)
    mv = memoryview(buffer)
    size=0
    ota_start()
    while True:
        chunk = f.readinto(buffer)
        if chunk > 0:
            ota_write(mv[:chunk])
            size += chunk
            print("\r%7d " % size, end="")
        else:
            break
    ota_finish()

[Paco88]

@robert-hh
I'm also trying. Occasionally I have memory allocation problems, nothing that can't be solved with the garbage collector.
Thanks for the tips

[mdnncl01]

Hi all guys, I'm a beginner in the Pycom and Python world. With my team we decided to start experimenting with these devices (WiPy),
but for us it is absolutely essential to update the OTA of the user application for a real use in the field. From all the discussions
and documentation this aspect is not very clear; It would also be nice to have a possible firmware upgrade of the module; this aspect
is also unclear. Is there currently a stable procedure to update at least the user application? I'm sorry for my english. Thanks