*Py: OTA firmware update incosistency

[robert-hh]

There is a little hiccup involved when you mix OTA and USB flashing.
OTA uses two memory areas for the firmware and toggles these. Let's call these A and B. On bootup, the bootloader checks a flag which area is active and starts this one. The USB flash always puts the image in area A and does NOT set the "active" flag accordingly. So, if the active area is B, and you do a firmware update by USB, the new firmware will NOT be excecuted. At the moment you can do two things:
a) erase flash, which will also clear the file system
b) do another OTA, which will set again A as the acitve area. Obviously you can use the new image.

There is another unrelated hiccup when alternating between firmware images downloaded from Pycom.io and self-built images. The partition maps seem incompatible, leading to either "Red LED frozen devices" or a corrrupted file system. In that case one has to erase flash and reload with the intende method.

[danicampora]

Thanks @robert-hh. The solution to both issues is to reset the OTA config area in flash when the binaries are programmed via the makefile. I will prepare that.

[nevercast]

I flash with the esptool directly sometimes, otherwise I flash the firmware using FTP OTA. Esptool approach seems to work, the firmware is updated and my new code runs. the FTP OTA does not seem to work.

Now without me derailing this thread, can you confirm if this issue I'm experience would be related to the OTA config area? If not, I'll make an issue elsewhere.

Kind regards,
Josh.

[robert-hh]

@nevercast I did not check whether and how this issue is still pertinent. When I wrote that, it seemed to be the opposite. FTP OTA worked, but depending on which image was set active, esptool.py loads would not get active. But I can re-check that. Take care, that you use appimg.bin for the OTA load.

[nevercast]

The image I'm pushing, is the product of
make all -j4 BOARD="$BOARD" TARGET="app" FROZEN_DIR="$FROZEN_DIR" FROZEN_MPY_DIR="$FROZEN_MPY_DIR"

Which gives me a wipy.bin. I then push wipy.bin to /flash/sys/appimg.bin

Is this correct?

[robert-hh]

No. make should also create appimg.bin in the same place as wipy.bin. appimg. differs from wipy.bin in that it is extended by a signature, which is checked by the OTA loader. If that is missing or not matching, OTA will fail. If you did not change the default places for all directories, a simple
make
should be sufficient. -j4 just speeds up the make process.

[nevercast]

Thanks @robert-hh, I'll copy the appimg out instead. Is the signature at the end of the application binary, i.e. Can I still use esptool also?

[robert-hh]

Why would you use esptool.py for OTA?

[nevercast]

Just to clarify, I'm now copying appimg.bin instead of wipy.bin. Using esptool to copy appimg works as expected, the firmware is modified. However copying appimg to /flash/sys/appimg.bin does not successfully modify the firmware. The firmware previously flashed with esptool is executed instead.

Here is my partition table generated from the make process.

Name	Type	SubType	Offset	Size
nvs	data	nvs	0x9000	0x7000
factory	app	factory	0x10000	1536K
otadata	data	ota		4K
ota_0	app	ota_0	0x1a0000	1536K
dummy	data	7		64K
fs	data	5	0x380000	508K
config	data	6		4K

It should be noted that with esptool I am flashing bootloader.bin to 0x1000, partitions.bin to 0x8000 and appimg.bin to 0x10000. (I'm also generating the flash with fuse and flashing that with esptool to 0x380000, but I don't believe that will affect this, it's 100k which does not exceed space allocated)

Appimg.bin is 1198K, and should not exceed space allocated

Unfortunately the bootloader and partition bin are not listed in the partition table above, so I must assume they are correct. Clearly I'm flashing the factory image and that works as expected. So then, it's the OTA that is not changing the config to ota_0 ?

My repo over at https://github.com/brushtechnology/pycom-micropython-sigfox does include commit c1a862b so it's my assumption that this shouldn't be a problem? I'll uncomment the printf statements in updater.c and see if that can provide insight.

[nevercast]

Update to this, I wrote a module to give me insight in to the updater and the boot info, this allowed me to notice that sometimes the update was considered finished before the ftp push had completed. Wireshark shows TCP Ack Dupes and packet drops. At this point, the issue might lay outside the updater code. I'll clarify that if I get a more certain cause.

[robert-hh]

The initial issue is not related to transmission errors. It also happen if the image is copied to the SD card beforehand. And the image loaded by OTA is always activated. It's just the image loaded by USB which might not run, if the "active image" pointer points at the second partition.

[nevercast]

Okay. Seems I agree with you, my issue is not related to this one. I'll raise another issue when I know more. Cheers

[nevercast]

I'm no longer seeing an appimg.bin, presumably, application.mk has changed and this file is no longer created. Do I still need it over the old wipy.bin?

Edit: Found this covered in the release notes here: https://github.com/pycom/pycom-micropython-sigfox/releases/tag/v1.17.2.b1

Keywords APPIMG APP_BIN

[catalinio]

hi Nevercast,

The appimg.bin is not created anymore, the wipy.bin has already the checksum included.
For the OTA updated, the wipy.bin needs to be copied and renamed to /flash/sys/appimg.bin
Furthermore, the USB/serial update (esptool) copies the same wipy.bin in the right OTA partition.

Let me know if it works, and if there is any other problem with OTA process.