Pymark sync project failed
-
Hi,
First I would like the thank you all for the help I’m getting on this forum!
Now I would like to make changes to main.py and boot.py.
So I created a new project in Pymakr and added these files in it.When doing Sync Project I'm getting "Syncing failed!" message.
I'm sure the serial connection is working.
I'm using Linux Mint 17.What went wrong? And how to solve this.
Kind regards,
Gertjan.
-
I found a partial solution to this problem.
The console always showed me:
"Syncing the project with the LoPy. Please wait...
Syncing failed!"
when I tried to load the Python scripts ino the LoPy.The solution I found was using a FTP to load the files.
Section 2.4 from this page shows you how to configure the FTP settings to be able to do so:
https://docs.pycom.io/pycom_esp32/pycom_esp32/toolsandfeatures.html
I used FileZila client and worked perfectly.
Make sure you connect to the LoPy WiFi to load the files with the FTP.
"Connect your computer to the WiFi network named after your board (e.g. lopy-wlan-xxxx, wipy-wlan-xxxx). The password is www.pycom.io"I could not make it work through the Pymakr but at least in this way I was able to load everything into the LoPy with no problems.
-
I've reformatted the flash drive. Now it appears as if boot.py is no longer executed (the flash operation removed my version, but I was able to put it back with ftp). It keeps going back to ap mode.
When I connect to the device through wifi (192.168.4.1), then I can now synchronize the project from pymakr. I can also ftp to the device (and see logging through the com port).
When I paste the code of boot.py into main.py and run that, it also connects to the wifi network in STA mode.
When the device is in STA mode connected to the wifi, I can still sync the project from pymakr and ftp, but when I remove the 'boot.py' code from main.py and reboot the device, it goes back to AP mode.This is the code I'm using in boot.py:
known_nets = [('xxx', 'yyy')] # change this line to match your WiFi settings #, ('office_ssid', 'office_password') import machine import os uart = machine.UART(0, 115200) # disable these two lines if you don't want serial access os.dupterm(uart) if machine.reset_cause() != machine.SOFT_RESET: # needed to avoid losing connection after a soft reboot from network import WLAN wl = WLAN() # save the default ssid and auth original_ssid = wl.ssid() original_auth = wl.auth() wl.mode(WLAN.STA) available_nets = wl.scan() nets = frozenset([e.ssid for e in available_nets]) known_nets_names = frozenset([e[0] for e in known_nets]) net_to_use = list(nets & known_nets_names) try: net_to_use = net_to_use[0] pwd = dict(known_nets)[net_to_use] sec = [e.sec for e in available_nets if e.ssid == net_to_use][0] wl.connect(net_to_use, (sec, pwd), timeout=10000) while not wlan.isconnected(): machine.idle() # save power while waiting except: wl.init(mode=WLAN.AP, ssid=original_ssid, auth=original_auth, channel=6, antenna=WLAN.INT_ANT)
I had a similar problem at the very beginning, but it was resolved after the first firmware upgrade succeeded. Now, the firmware upgrade can still be done successfully, but the device does not want to connect to my wifi from boot.py.
-
@Jan What kind of code is run by LoPy. So blocking connectivity.
With soft-boot I mean using the wires so boot.py and main.py are skipped. Read the manual how to do this.
After a real soft-boot you should be able to connect with FTP.
Also open Pymakr (or telnet) and check if serial connection is working.
Do a soft reset (using the reset button) and check the serial output.Pymakr project sync doesn't work because code signature check doesn't work yet (as stated in this threat earlier).
-
@Jan, can you try reformatting the internal storage?
import os os.mkfs('/flash')
Please post back your results :)
-
I can connect to it by wifi. I can issue the commands. It also did a soft-reboot (done from within pymakr using ctrl+D).
It just wont sync the project. I figured out why the ftp didn't work: after trying a sync with pymakr, the connection appears to be locked. After a device reboot, it's possible again to connect with ftp. The file system still appears locked though: I can't add or remove any files. It contains a couple of files with 0 byte length. (leftovers from project sync attempts).
-
@Jan Did you tried to boot in soft-boot mode?
Then you should be able to connect to it by WiFi.
FTP should work also from then.
Succes1
-
That jumper indeed got stuck in the bag. I found it at the bottom. Now the upgrade tool works, but I'm still getting the same problems in pymakr for syncing the project. Also can't ftp anymore to the device (target machine actively refused the connection).
-
@Jan Try it again with the TX jumper on the expansion board. Without it the update will fail. Sometimes this jumper gets loose in the package, so it might still be in there. Otherwise take the BAT jumper and put it on TX.
-
It's indeed the pycom expansion board. The entire row has jumpers, except for TX and RTS
The upgrade tool runs from a windows 10 machine, not virtualized.
I first tried the pyCom firmware update tool from the downloads section
That kept reporting that it failed.
Next, I saw a bunch of forum posts that were talking about running the upgrade tool from the command line, which also didn't work.
Tried the communication channels: AP mode was basically the only thing that worked as expected.
Finally, I found this article: https://forum.pycom.io/topic/166/how-to-really-solve-the-firmware-update-failures which at first also didn't work. So then I started looking at the hardware/serial communication and tried with a basic arduino programmer + some wires. Then started again with the 'how-to-solve-the-firmware' procedure, which worked.
All communication channels began working (serial, wifi, AP), except for ftp (didn't try lora yet).
-
@Jan, we suspect your board suffers from a write protected memory. This is caused by a bug in the ESP32 code provided by Espressif that was available by the time your board was manufactured.
There is a way to fix it, and that's why we're shipping the firmware upgrades with a tool. I must advice you to try upgrading using the tool. The procedure you mention is old, unofficial and hence, unsupported. I will try to help you make the official one work for you.
You mention a shield, I don't know if it means a Pycom Expansion board. If that's the case, please check that all the jumpers on the corner are present (we've heard of cases of missing jumpers). If you don't have an expansion board is ok, any serial adapter will work.
Can you please provide more information on the upgrade issue itself. What things did you try that didn't work, what kind of operating system are you running the upgrade into, is it a virtualized environment?
Regards,
Abilio
-
Getting it upgraded was a pain in the *** It didn't work with the shield, so I used an arduino programmer to connect the device. Then, I followed this procedure: https://forum.pycom.io/topic/166/how-to-really-solve-the-firmware-update-failures It was the only one that worked for me.
-
@Jan, you mention you upgraded from 0.9.0 to 0.9.6. The fact you mention it also fails using FTP gives us a hint. To confirm it, can you please explain what method did you use to upgrade your firmware?
-
@Ralph
The files get created, but are not copied over. I have the same issue with the ftp client (winscp).
I'm running windows 10
os.uname() gives: release='0.9.6.b1', version='v1.8.6-40-gd10463e on 2016-11-25' (I managed to upgrade from 0.9.0.0)
pymakr version = 1.0.0.b7
-
@Jan yes the sha256 problem was solved in one of the releases last month, but I've not heard your problem before. If you create a new python file in your Pymakr project, named something else than main or root, and then press sync, it should also place this file on the board. Did you check if the file was there using FTP?
-
has this problem been solved already? I am still not able to upload other files to the system, only the main. and root.py
-
Pymakr uses sha256 to validate the correct transfer of the files. Due the fact that the LoPy/WiPy2 are still missing the sha256 module, this part fails. The next Pymakr release will include a fix for this issue.
Thanks for your patience and support,
Abilio