Pymakr/VScode sync problems

[Ralph]

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.

[Martinnn]

@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.mkfs

The 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.

[Ralph]

@martinnn Ok, thanks for confirming all that!

1. 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.

2. 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.

[Martinnn]

@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.

[Ralph]

@martinnn

1. 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.

2. 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.

[Martinnn]

@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!

[Paul Thornton]

@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

[Martinnn]

@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.

[Ralph]

@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

[Martinnn]

@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).

[Ralph]

@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.