OTA or not OTA that is the question...
-
@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
-
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?
-
@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.
-
@robert-hh
Yes. But i'm having problem with the download of apimg.bin from the wipy.
-
@Paco88 So you're aiming at a device updating itself?
-
@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.
-
@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.pywith commandread_flashthough I'm not sure you can get exactly the same data as theappimg.bin.
-
@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.
-
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.
-
@jcaron Thank @jcaron for the explanation. A few notes to be added:
- 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.
- 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
- 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.
-
@BetterAuto The very high-level procedure is:
- 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)
- 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.
- Upload the file
pycom-micropython-sigfox/esp32/build/LOPY_868/release/appimg.binto/flash/sys/on your module via FTP. - Reset
-
So could someone please share high level details about the procedure?
-
@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.
-
@Paco88 OTA works. I use it for a lolin32 device where the USB/UART chip is not working reliably.
-
Any news about the OTA features?
-
@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?
-
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
-
@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
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)
-
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
