Pymakr/VScode sync problems
-
I have the latest pymakr (1.0.6) and VSCode (1.31.0), but the problem was the same with the previous version (1.0.5/1.30). Wipy/Pysense.
I edit a local source file, save it and press upload in the lower left pymakr command bar. Often I get an error:Pycom MicroPython 1.18.2 [v1.8.6-849-07a52e4] on 2019-02-08; WiPy with ESP32
Type "help()" for more information.Uploading project (main folder)...
Not safe booting, disabled in settings
Reading file status
Failed to read project status, uploading all files
Creating dir appl
Creating dir appl/cert
Creating dir appl/lib
[1/31] Writing file appl/basic_view.py (1kb)
. . .However, the file I edited (and I was sure I saved it in VSCode) is unchanged on the wipy, although it is shown in the "writing file..." list. This is quite annoying because you try to fix some error and really scratch your head why it doens't work, until you realize that your changes aren't uploaded!
Only way to fix it is to format the file system, os.mkfs('/flash').
This is a very time consuming process:- Upload
- get error and wait until all 31 files are uploaded
- test test test - is the code working? no?
- format flash
- upload again all 31 files...
Any chance how to debug this? What is causing the "failed to read project status"? Why does the complete upload fail?
-
@martinnn Found the issue with your firmware updater. If you would want to update to a dev version, you need to download the development version of the firmware updater (here). They will release it as stable soon, but not until then, use this dev version.
-
@ralph of course I'll have to test it a bit longer to give you a definite statement, but it looks like:
- resetting the board via ctrl-f instead of pressing the reset button does not solve the read status error (still fails from time to time).
- however, I did not yet have an upload failure. Either pymakr uploaded all 31 (read status error) or just one file, but upload seems to correctly upload all files (for the time being).
-
@martinnn Ah you're right, ctrl-f is grabbed by vscode by default! I'll fix that, but you worked around it already.
So, safe booting using ctrl+f manually before each upload, solved your issue completely? Both the read project status error and the files not updating to the last version? safe_boot_on_upload is supposed to do the same thing, but maybe there's a bug.
Compression will indeed not work on 1.18.2, it only works on 1.20 :) I'll come back to you about the firmware updater error
-
@ralph Tried pressing ctrl-f then uploading a few times and it works so far. Enabled safe_boot_on_upload and tried this with my application running - didn't quite work, failed to read project status... but no upload error.
Then I tried to switch the compression on:
Pycom MicroPython 1.18.2 [v1.8.6-849-07a52e4] on 2019-02-08; WiPy with ESP32 Type "help()" for more information. >>> Uploading project (main folder)... Safe booting device... (see settings for more info) Reading file status [1/1] Writing file appl/s3iotlogger.py (10kb) with compression Failed to write file, trying again... Failed to write file, trying again... Filecheck failed Upload done, resetting board... OKets Jun 8 2016 00:22:57 rst:0x7 (TG0WDT_SYS_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:1 load:0x3fff8028,len:8 load:0x3fff8030,len:1688 load:0x4009fa00,len:0 load:0x4009fa00,len:14592 entry 0x400a059c booting... Main to be launched is: /flash/appl/s3iotlogger.py Launching application appl Traceback (most recent call last): File "/flash/appl/s3iotlogger.py", line 1 SyntaxError: invalid syntax Pycom MicroPython 1.18.2 [v1.8.6-849-07a52e4] on 2019-02-08; WiPy with ESP32 Type "help()" for more information.Didn't work, corrupted the file.
-
@martinnn said in Pymakr/VScode sync problems:
I always reboot my wipy before syncing. The code that normally runs starts the MQTT background task and also the watchdog, which messes up with the upload. I have a boot.py that checks if the user button on the pysense is pressed and if yes, runs a "donothing.py" that does just that, exits to a clean repl with nothing else running.
Thats actually a pretty decent trick. :D
-
@ralph I'd try CTRL+F, but it opens the find dialog in VSCode!
EDIT:
{
"key": "ctrl+alt+f",
"command": "workbench.action.terminal.focusFindWidget",
"when": "terminalFocus"
},
seems to work!
-
-
an easier alternative for that is just pressing ctrl + f in the pymakr terminal, to do a safe boot that skips running the boot and main file. In any case it should be fine, and I'm not sure why the project status fails to read sometimes.
-
I have seen the FAT file system getting corrupt, but it's rare. I wouldn't expect it to happen so frequently. Maybe try the ctrl + f safe boot before upload, instead of your reset system, and see if that makes a difference in behaviour.
-
-
@ralph 1. I always reboot my wipy before syncing. The code that normally runs starts the MQTT background task and also the watchdog, which messes up with the upload. I have a boot.py that checks if the user button on the pysense is pressed and if yes, runs a "donothing.py" that does just that, exits to a clean repl with nothing else running.
2 I am using the normal FAT file system. Is it possible that it is corrupted by a reboot? As I said I have lots of resets - no other way to get rid of the background thread and the watchdog. Either (if application is running) by pressing the user button, which in the code then executes a machine.reset or (if something is stuck) by pressing the reset button.
-
@martinnn Ok, thanks for confirming all that!
-
So 'failed to read project status' means something went wrong reading the latest state of the files on the board, which means it can't compare changes and it'll upload everything. Reason can be a lot of things, like code running on the board blocking pymakr actions or the board running out of memory.
You can solve it by either stopping the code manually before upload (pymakr does a ctrl-c, but that doesn't always stop the code) or enabling a safe-boot before upload (same as manual ctrl-f), which is the best solution. -
The thing I don't have an answer for is Pymakr saying it's uploading your file, but it not writing the latest version of it. I've not seen that before. Are you using the normal Fat filesystem or littleFS?
Not sure about the firmware updater not working when you set it to development, I'll ask it's developer about it in a bit.
-
-
@ralph Lots of questions... There are two problems.
1: failed to read project status... wastes a lot of time (why does this happen)
2: uploading all files does not work correctly
All those 31 files are already on the board, one (the one I edited) being outdated (I verified this by connecting via FTP)
I don't see a "failed to write" error.
So it is an upload error. The old file is on the wipy, the new one on the PC, pymakr says "writing file xxx.py", after this there still is the old file on the wipy. Only fix: os.mkfsThe Wipy is on a unmodified pysense, don't know about safe boot pins (I assume they aren't connected).
Some files go into the root folder, some into the appl directory and so on. This is the intended behaviour (and it works most of the time).
How do I upgrade to the 1.20 rc - the pycom firmware updater gives an error: Firmware file has unexpected sha1 checksum if I set mode to development.
I'll try the safe_boot_on_upload.
-
I made a mistake with the firmware versions there. 1.18.2 is the latest stable, which you're on. 1.20 is the latest dev. You could try that, but 1.18.2 should work fine.
-
Hi @Martinnn, thanks for the extended report and sorry you're having issues.
So if I understand it correctly, Pymakr is showing output as expected but the changes it says it writes to the board are not actually stored on the board. Yet sometimes it fails to read the project status, resulting in 31 file uploads. Are all those 31 files NOT showing up on the board at all? Or are the 31 files present, but in an older state?
You don't get any 'failed to write file' errors after any of those writes? You're not rebooting with the safe-boot pins connected by any chance, right? Also, is it your intention to upload your files to the 'appl' folder on the board, like your output is showing?Some things you can try:
- Update the board to latest firmware (I think we're on 1.20.x now)
- Enable safe_boot_on_upload in general settings
Curious to see if that changes any of the above behaviour.
