@Xykon When I was helping @ArnaudP to resolve the problem with FiPy modem f/w update (sqnsupgrade.run('/sd/CATM1-version.dup', '/sd/updater.elf')) from initial release, we went this path: upgraded FiPy from 1.10.0.b1 to the latest stable 1.18.1.r4 on FiPy 1.18.1.r4 modem f/w upgrade to the newest CATM1-39529 failed on FiPy 1.18.1.r4 modem f/w upgrade to previousCATM1-38638 failed downgraded FiPy from 1.18.1.r4 to 1.18.1.r1 on FiPy 1.18.1.r1 modem f/w upgrade to CATM1-38638 successful now I'm waiting for @ArnaudP feedback about modem f/w upgrade to CATM1-39529 on FiPy 1.18.1.r4 What I've noticed is that updater.elf file in the previous CAT-M1/NB1 releases is the same and with a size of aprox. 300KB, but for the latest they are different for CAT-M1 (420KB) and NB1 (364KB). I've been told by @ArnaudP that he had already sent you a message.

@rossdem699 You can use the pycom updater. Start the Pycom updater and tell it to update from a file. When it asks for a file, give it the name of the zip file. The updater will unpack the file itself. Generally you may also use ftp OTA update. Take the appimg.bin file from the package and transfer it to flash/sys. Once that is finished, reboot the device. But for a large change like 1.18.1r1 to 1.19.0.b4 and its possible change in the flash layout this may not work.

Hi @lasse You can find the firmware releases on GitHub: https://github.com/pycom/pycom-micropython-sigfox/releases I'll look into creating a page for changelogs somewhere.

@cmisztur Editing pycom-micropython-sigfox/esp32/pycom_version.h you can change the version, but I don't know how to change the name and the other parameters returned by uos.uname(). I'm sorry. Regards,

Resolved... diff --git a/py/mkrules.mk b/py/mkrules.mk index 633b0df..b9b235c 100644 --- a/py/mkrules.mk +++ b/py/mkrules.mk @@ -115,6 +115,13 @@ FROZEN_MPY_PY_FILES += $(shell find -L $(FROZEN_MPY_DIR)/Common/ -type f -name ' ifeq ($(BOARD), $(filter $(BOARD), GPY FIPY)) FROZEN_MPY_PY_FILES += $(shell find -L $(FROZEN_MPY_DIR)/LTE/ -type f -name '*.py' | $(SED) -e 's/$(FROZEN_MPY_DIR)\/LTE\///') endif +else ifeq ($(findstring MINGW32,$(OS_NAME)),MINGW32) +# make a list of all the .py files that need compiling and freezing +FROZEN_MPY_PY_FILES := $(shell find -L $(FROZEN_MPY_DIR)/Base/ -type f -name '*.py' | $(SED) -e 's/$(FROZEN_MPY_DIR)\/Base\///') +FROZEN_MPY_PY_FILES += $(shell find -L $(FROZEN_MPY_DIR)/Common/ -type f -name '*.py' | $(SED) -e 's/$(FROZEN_MPY_DIR)\/Common\///') +ifeq ($(BOARD), $(filter $(BOARD), GPY FIPY)) +FROZEN_MPY_PY_FILES += $(shell find -L $(FROZEN_MPY_DIR)/LTE/ -type f -name '*.py' | $(SED) -e 's/$(FROZEN_MPY_DIR)\/LTE\///') +endif else # make a list of all the .py files that need compiling and freezing FROZEN_MPY_PY_FILES := $(shell find -L $(FROZEN_MPY_DIR)/Base/ -type f -name '*.py' | $(SED) -e 's=^$(FROZEN_MPY_DIR)\/Base\//==')

@robert-hh I thought so. Thanks.

Solved. My mistake. I just connected to the expansion board, without the WiPy module on top of it. Then it had the error. With the WiPy module connected to the Expansion board, and following the instructions, the firmware update went fine.

@robert-hh said in LoPy link error: pycom-esp-idf That was the problem. Thanks - everything works and firmware flahses fine.

Hi @terryz, This is not a bug, the firmware updater works as expected, your antivirus software has an issue. Someone else had an issue similar to this, in that case the reason was that the firmware updater connects to the internet and that's considered "suspicious" for some anti-virus applications. If you add it to the exception list, you can continue using it.

@jirkakrepl Thanks. I had worked this out.

@robert-hh A further look revealed, that both the LOPY4 and FIPY image are below 1536k. Only if I add one of the IN865 or EU433 regions AND my favorite frozen scripts, the FIPY build exceed 1536k. Still some slimming is advised, or more room in the partition table.

@robert-hh Because we only changed 3 lines of code and released only versions for GPy and FiPy. That didn't seem to warrant anything more than updating the release tag. In case you are wondering, 1.18.0 is considered a short form of 1.18.0.r0 as we consider r0 the default unless otherwise specified. From a viewpoint of our internal versioning algorithm, we have 4 different types of versions: 1.18.0. a0 is an alpha version (only used internally), b0 is a beta (up until 1.18.0 everything was released as a beta even though the firmware updater treats them as stable), rc0 (release candidate, we never used this so far but we have the option for it) and r0 as stable release.

@jadowdl You do not need an expansion board. Almost any USB/UART bridge and a few cables will do. You just have ot take care that the USB/UART bridge can supply 5V while the UART signals are at 3.3v. If you already have a REPL prompt through USB, then you are almost set. The only additional step for upload is to connect P2 to GND and pzsh reset. About Pin numbers, look here:https://docs.pycom.io/chapter/datasheets/development/gpy.html

@brady-aiello For the old expansion board you do not need the DFU drivers, as it uses an FTDI or similar USB/Serial bridge. it should work out-of-the-box. If you installed drivers according to the instructions you cited, remove them. See also the instructions here https://docs.pycom.io/chapter/gettingstarted/installation/firmwaretool.html#first in the expansion board 2 tab. Some people had trouble with Windows and the V2.x expansion board, and there is a lot of discussion around it in the board, which sometimes is more confusing than helpful. As result of that, the instructions in the manual were updated. b.t.w.: I prefer the V2 expansion board. Updating with the expansion board V3 or the pyxxxx board seems inconvenient, as it requires unplugging and replugging the board with a tight timing and reconfiguration of each OS.