GPY full flash erase

[kjm]

OK I've figured out that the pycom-fwtool is part of the updater & a test command worked

C:\Program Files (x86)\Pycom\Pycom Firmware Update>pycom-fwtool-cli.exe -p COM3 chip_id
Running in FTDI mode
ESP32D0WDQ6 (revision 1)

No obvious reason why the adhoc wifi is gone after the change to 1.20.1.r1 though

C:\Program Files (x86)\Pycom\Pycom Firmware Update>pycom-fwtool-cli.exe -p COM3 wmac
Running in FTDI mode
WMAC=30AEA42A6AB4

it knows it's wifi MAC

Anyway I'm anxious about trying the full flash erase considering "Erase entire flash, only use this if you are sure you know what you are doing. This will remove your devices lpwan mac addresses etc." at https://docs.pycom.io/advance/cli/ At the moment 1.20.1.r1 has delivered reduced functionality (no adhoc wifi) I'm worried the full flash erase could leave me even worse off.

[robert-hh]

@kjm The LPwan mac and sigfox addresses are restored during the firmware install using the pycom updater. So this is not a risk, and the robust method to start over with a defined state. Since I try a lot with my devices, I have to do that full erase from time to time. I cannot tell anything about the ad-hoc wifi, since Im using STA mode in the local network, which anyhow requires a dedicated set-up of the WLAN. You can always do that specific set-up in your boot.py or main.py, if needed.

[kjm]

I'm not sure how to do an adhoc wifi setup in boot.py Rob. I tried pycom.wifi_on_boot(1) to get adhoc wifi back but it doesn't work. Any tips?

[kodarn]

@kjm I had problem with the AccessPoint not initializing on 1.20.1.r1 release. However, that all went away when I did the "erase_all", and then reflashing 1.20.1.r1 again.

[kjm]

@kodarn Was that on a GPY?

[kodarn]

@kjm Ah, um, no, it was on a LoPy4 board.

[Clemens]

It was a nice feature before that a new (firmware flashed) device was accessible by WiFi this is gone with the 1.20.1 release and makes the setup for some scenarios more complicated. I fear this feature was switched off to be replaced by PyCom's own setup wizard via pybytes in the future.

[robert-hh]

@kjm I tested this short script, and it sets up the AP. Note, that you can set ssid, password, and IP address as you like. The DNS settings are more or less useless.

#
# set device in AP mode
#
from network import WLAN
wlan=WLAN(mode=WLAN.AP, ssid="my_wlan_1", auth=(WLAN.WPA2, "wlan_password"))
wlan.ifconfig(id=1, config=("192.168.4.1", "255.255.255.0", "0.0.0.0", "0.0.0.0"))

[robert-hh]

@Clemens In my homebrew 1.20.0.r1 this feature is still present. It could be related to the fact, that the version 1.20.1 you can install via the pycom updater is a pybytes variant. For that, the automatic AP setup my be not useful, since that prevent access to the internet.

[robert-hh]

@kjm I do not assume that GPY and the other board behave different with respect to WiFi.

[Clemens]

@robert-hh we at hiveeyes use and promote your firmware build as a good medicine in case the official version makes problems. So many thanks for this. It's a bit pity that you have to do the work pycom should jump in normally!

[kjm]

@Clemens I'm confused now. Are there two different 1.20.1.r1, the official pycom one & Rob's? We don't use pybytes so I'd be keen to try Rob's. Where can I get a copy & what do I use to load it if the pycom updater only does the pybytes variant?

[robert-hh]

@kjm You can always build the firmware from the sources. That's easiest done on a Linux system. A virtual machine or WSL of Windows 10 also works. The latest version of the Dev branch creates the tar bundles, which can installed using the Pycom updater. On Linux system, you can do that also w/o the pycom updater. Using the Pycom updater has the advantage, that ot resets the Lora and Sigfox MAC, if that was lost after a full flash erase.

Nevertheless, going that way is a big initial step, if you are not used to it. For Linux, any old system is sufficient, which many people may have around. Using Xubuntu or Mint xfce is an easy install process. Setting up the build environment is documented, but there are quite a few chances to omit things.

b.t.w: I could update my pre-built bundles.
b.t.w.2: I asked several times also to update the "official" non-pybytes variant. I think pycom refuses to do so, promoting pybytes as their entry into a service business.

[crumble]

@robert-hh said in GPY full flash erase:

I think pycom refuses to do so, promoting pybytes as their entry into a service business.

Pycom marked the "normal" firmware as legacy. So I do not think, that they will update this branch.

[andreas]

Hi there,

we might want to divert that to a different forum thread, but just for the sake of completeness we also started brewing our own firmware images and publish them to [1]. Please let us know if we can be helpful for the community in any way on this topic.

Cheers,
Andreas.

P.S.: Disclaimer: @Clemens and me are on the same team working on a datalogger software called Terkin for MicroPython [2]. We learned many things from @robert-hh and are taking different kinds of deep-dives into things we wouldn't better not have known about [3].

[1] https://packages.hiveeyes.org/hiveeyes/foss/pycom/
[2] https://community.hiveeyes.org/t/developing-terkin-for-micropython/233
[3] https://community.hiveeyes.org/t/random-memory-corruption-faults-on-esp32-wrover-rev-1-and-rev-2-when-running-in-dual-core-mode/2515

[robert-hh]

@kjm Looking at the source code I can see, that the WiFi settings for boot are now taken from a flash configuration data set. I did not dig further about how this data is set. The intention may be to set that in the pybytes configuration dashboard. Since my devices start that AP with software implementing that property, and these have been erased, It may be that the default is: start the AP.

[kjm]

@robert-hh I'm still confused. Am I right in thinking there are two 1.20.1.r1 firmwares now? The pybytes version (which has no adhoc wifi) that the pycom updater will install and your version that I have to assemble on a linux machine before I can install it?

[andreas]

@kjm Anyone can build firmware images from the sources. Pycom is obviously featuring their offical firmware builds stronger with respect to features of their product platform while we are aiming to freeze our foundation modules into different builds in order to brew customized firmware images better fitting the requirements of our community.

[robert-hh]

@kjm As @andreas told, the firmware builds I make are not that special. They include only my favorite scripts as frozen bytecode, and I have tailored the build scripts to support my build environment. Sometimes I try special variants, like a version the supports Lora EU433, or an option to invert UART, .....,
It is not explained by PyCom, which of the various branches in the PyCom repository is the recent "official" one. By convention, it should be 'master'. But the actual development seems to happen at Dev (tagged as default), which seems to include the pybytes code. But there is also a branch called 'pybytes-master'.
Edit: This is the list of actual branches with their most recent update times:

Dev (default)           Oct 30, 2019
Release/v1.20           Oct 7, 2019
pybytes-master          Oct 5, 2019
OTA_1_20_Prep/master    Sep 15, 2019
fw_fixes                Sep 10, 2019
release-candidate       Aug 22, 2019
Release/v1.18           May 15, 2019
master                  May 14, 2019
bug_fixes               Apr 15, 2019
pypic_pid_fix           Mar 1, 2019
development             Nov 12, 2018
spi_bitorder            Nov 7, 2017

[kjm]

@robert-hh I don't think I'm smart enough to roll my own firmware. When I run the latest Windows pycom firmware updater it starts by telling me the latest firmware is 1.16.1 but then later it says it downloaded & used 1.20.1.r1 I assume that's the Oct 5th pybytes-master in your list, with no adhoc wifi? How is this different from Oct7th Release/v1.20?