OTA or not OTA that is the question...

[robert-hh]

@Innocenzo When you say "previous", which version was it?

[Innocenzo]

@robert-hh I am sorry, but I do not remember precisely. Or the first release of 1.7 or the the latest 1.6 ( I had to change the file bootloader.h for IMG_SIZE field).

[jmarcelino]

@robert-hh
Back in April I flashed a 1.6.9 custom firmware OTA with a the simple partition size patch - change #define IMG_SIZE (1536 * 1024) in the bootloader.h. It was definitely running my OTA image as I changed the version string and added an extra function.

Haven't really tried it since then. I think the code is already all there but as it was suggested maybe the bootloader isn't stable, the partitioning is still in flux or maybe it'll change to be connected in some way to the Pybytes platform.

[robert-hh]

@jmarcelino At the moment it is defined as:
#define IMG_SIZE ((1024 + 512) * 1024)
So I'm not sure what#s going on. I tried to upload an self-compiled appimg.bin. I could try to extract that from the 'official' image and try again.

[BetterAuto]

If the issue is only one of storage space, perhaps a smallish external SPI flash. Cheap.
https://www.digikey.com/product-detail/en/winbond-electronics/W25Q64JVSFIQ/W25Q64JVSFIQ-ND/5803990

[jmarcelino]

@BetterAuto
There is enough storage space, all the kits have 4MB Flash. The partitioning setup allows for two 1536K application images (factory + OTA) and a 508K user area (what you see in as /flash)

[robert-hh]

@BetterAuto At the moment it looks like only a somewhat small piece of software bug has to be changed. Maybe the same that causes the pre-build imagas and self-built images to be incompatible = using a different partitioning of the memory.

[BetterAuto]

I just found this post from back in April with a method from @jmarcelino which may be useful for us. I haven't tried it yet.
https://github.com/pycom/pycom-micropython-sigfox/issues/5

[robert-hh]

@BetterAuto The carnage @jmarcelino ist set by default now. You can do an OTA upload this way, but then the device either does not start any more or the uploaded image is ignored, depending on which state the device was before. There is a discrepancy between the partition as defined in lib/partitions.csv, compiled to partitions.bin, and the address definitions of bootloader.h. According to partitions.bin, the addresses where the image is stored with OTA is 0x10000 or 0x1a0000, according to bootloader.h it's 0x10000 or 0x190000. And some of the flags that are used to control the process are taken from the sixth partition called dummy, but the 4th partition is called ota_data, and may be the right one. The layout of memory and its use is not clear to me, and instead of me guessing, someone from pycom should fix that in the intended manner.
@daniel, what's your opinion?

[Paco88]

Any news about the OTA features?

[robert-hh]

@Paco88 OTA works. I use it for a lolin32 device where the USB/UART chip is not working reliably.

[jcaron]

@Paco88 I can confirm OTA works, at least if the version you're upgrading from is relatively recent. I think something like 1.6.whatever is required.

You'll need to build the image yourself though.

[BetterAuto]

So could someone please share high level details about the procedure?

[jcaron]

@BetterAuto The very high-level procedure is:

1. Make sure the board already has a firmware version that is recent enough to support OTA (I believe it needs to be >=1.7.7b1)
2. Follow the instructions here: https://github.com/pycom/pycom-micropython-sigfox to build the new firmware. IIRC I had to download and install a slightly different version of the Xtensa toolchain than the one linked to there, but YMMV.
3. Upload the file pycom-micropython-sigfox/esp32/build/LOPY_868/release/appimg.bin to /flash/sys/ on your module via FTP.
4. Reset

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