Pycom Updater: Wrong device type assiged
-
Which information is used py the updater to determine the type of the board. I have
- one LoPy4, WMAC 30AEA47852E8, which is seen as FiPy
- one FiPy, WMAC 807D3AC2EC50, which is seen as LoPy 4
and - another FiPy, WMAC 807D3AC30C38, which is correctly seen as Fipy (strange, isn't it?)
-
@robert-hh said in Pycom Updater: Wrong device type assiged:
What's new in this version?
The main thing is that it's built based on Espressif IDF 4.0 and includes BLE Mesh support as well as LoRaWAN specification version to 1.0.3 (Class A & C for now, we're working on support for Class B).
We're still working on some issues mostly around firmware size so the source code is not yet available.
More details can be found here: https://forum.pycom.io/topic/6107/new-beta-release-v1-20-3-b0
-
@Xykon Thank you very much for updating the data base. It works fine now.
Yes, I know the link to the tarballs. But what people seem to miss are more recent firmware versions in the legacy branch. Not everyone need pybytes. But at least the newer versions allow to bypass it, being it only dead code in the end.
I've notice also the development release 1.20.3. What's new in this version? After loading, it mentioned micropython 1.11. I cannot remember if that is new for the Pycom branch.
-
@robert-hh Hello Robert, yes the software server is using the Wifi Mac for device identification. I'm not sure how these got mixed up but I've corrected them in the database.
All the tar.gz files should be available at these links https://docs.pycom.io/advance/downgrade/ including the current 1.20.2 release (the latest development release 1.20.3 is under the "Legacy and previous development firmware" section for now). Let me know if anything is missing.
-
Hi,
You are indeed correct, the Device ID (WMAC) is used in our updater server as the module identifier. The first time you update your module using the firmware updater, you actually get to choose your device type, fixing it in our records. This also fixes the LoRa MAC and SigFox PAC etc. in our database, as they will get erased when the device is fully erased, making it possible to recover them when using the firmware updater tool (like described in the link you posted)! I've discussed with @Xykon, he will update the device types in our database for you, so they will work correctly with the firmware updater tool :)
Gijs
-
@Gijs Thank you for the response. I know the mechanism well, and had also restored previously the LoRa MAC using the method describer here by @Xykon : https://forum.pycom.io/topic/1272/lora-mac-ffffffffffffffff/6
It's not so urgent to use the Pycom Updater. I usually build my own firmware. But sometimes I want to load the "official" builds, and some of the versions are not available as tar package, like for instance all 1.20.2.rcx versions. And then the proper device should be selected. I confirm that that is based on a database at Pycom. So my question is still: which data element is the key for that database? I guess it is the WMAC, because that should be immutable and buried down in the ESP32 efuses.
-
This is a weird one. I wanted to give the same solution as you have given here:
https://github.com/pycom/pycom-micropython-sigfox/issues/386 ;)
Also after trying it myself, it does not work as expected. I believe (but do not quote me on this!) the firmware update tool checks the serial number to a Pycom database and also retrieves the other keys from there, when the device is fully erased.
In the meantime, you can grab the compiled fipy firmware from here: https://software.pycom.io/downloads/FiPy.html and upgrade the firmware 'from local file'. If you then check the firmware in pymakr usingos.uname()it should show up as a FiPy (with modem etc)
Let me know!
Gijs
