OTA or not OTA that is the question...

[robert-hh]

@jcaron Thank @jcaron for the explanation. A few notes to be added:

1. Once you have set-up your own build environment, you can also put you own Python scripts into frozen bytecode, just by placing them into the "frozen" subdirectory before running make. That save RAM and speeds up loading of modules substantially, since the code is executed from flash and no RAM is needed for parsing & compiling.
2. You can also download the image by USB using the command "make flash", or erase flash with "make erase". The latter is required, if you move from the pycom downloader to the your own images. If the LOAR mac is lost, today a fix was made public here:https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/21
3. An observation that may have been fixed meanwhile: If you mix the use of USB downloads and OTA downloads, you might see that a newly loaded image is not used. The reason: there are two reserved areas for the firmware image. OTA uses them alternatively, while the USB loader uses always the same area.

[Paco88]

Thanks to all of you!
I know that is possible tu update by putting appimg.bin in folder sys by ftp.
What i need is to download the appimg.bin FROM the wipy.

[robert-hh]

@Paco88 Why would you need that. It is available outside the flash. And if you need it for a different purpose on a WiPy node, you can attach a SD card and store a copy there.

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