@johand Thanks for the info, I'm able to reproduce the issue. There's indeed a problem in the upload feature, which has been solved in the latest versions of Atom. The VSC plugin is a bit behind code wise. We're working on a refactor of the Atom upload feature right now, when that's done we'll upgrade VSC as well to be up to date with it. That'll solve this issue.
For now either be a bit patient with uploading with VSC or temporarily switch to Atom for this project. Sorry for the inconvenience!
That diagnostic seems to reference VisualStudio rather than Atom. The pymakr plugins for VS & Atom are different as far as I know, are you sure you have the right one?
As far as Atom goes you probably need to roll back. https://forum.pycom.io/topic/6970/pymakr-not-compatible-with-atom-1-56/7
I have found this project on github that aims to resolve this kind of issue.
I wonder if Pycom might contribute to it, to enable pukka linting of code in Atom/Pymakr.
I just downgraded my VSCode to 1.52.1 (November 2020), forgot to disable auto-upgrades, and it re-upgraded to 1.53.2. Although was the same version as before, now the pymakr plugin is working correctly with my lopy...
Running on Windows 10, using FTDI usb-serial with W10 usb serial driver....
Could you perhaps elaborate on the issues you are experiencing?
Below I have provided an example of how to setup a connection to pybytes (and make sure that it is activated on boot)
You can then use pybytes.send_signal(1, your data) to make it show up on the platform
@robert-hh Thanks for the mention of the -c option! I did not know this, but it works! No more resets needed between commands.
And yes, I understand that I do not need to erase the flash every time I load a new firmware. But my example was trying to show that any 2 commands in a row had the same behaviour, for example:
Run pycom-fwtool-cli -p COM7 lpwan
The correct output is shown, with the SMAC, SID, PAC and LORA REGION
Run pycom-fwtool-cli -p COM7 lpwan once again, without resetting LoPy
The same error occurs: Exception: Failed to connect to ESP32: Timed out waiting for packet header
Now, with the -c option enabled, the procedure above works! Thanks so much!
@troy-salt it should definitely be something you can control, though, so you can decide to which version you want to upgrade, and which devices should be upgraded.
Many past firmware versions have broken quite a few things, so you need to be able to test any new firmware on a limited set of test devices before deploying it widely.
@papasmurph I just ran into the same issue even though I checked the "include development Software" and I had the boards (patate and WiPy) already setup and running before I did the upgrade. I tried to clear the user space as well and go through a clean build but still stuck. I am stuck with the same error :
Starting LoRaWAN concentrator
Traceback (most recent call last):
File "main.py", line 26, in <module>
AttributeError: 'module' object has no attribute 'callback'
Pycom MicroPython 1.20.2.r0 [v1.11-783192e] on 2020-08-06; WiPy with ESP32
Pybytes Version: 1.5.1
Anyone faced this issue ?
@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