sg-wireless/pymakr-vsc

pymakr doesn't connect to the board any more

Opened this issue · 10 comments

cristian-spiescu commented

I installed the extension v2.22.5. I played a bit w/ it. I had some issues and I wanted to try Pymakr preview, v2.25.2. When installing this version, among other issues (such as not recognizing the project I created previously), no connection could be established:

image

I tried rebooting the device. I uninstalled the preview version and reinstalled the main one. Same result. Connection via another app was possible.

UPDATE: and while writing this bug report, as if magic happened, the connection started to work again. However, I observe that when I boot VS Code, I get this. I don't know where to look for more info:

image

Additional info: ***

Config
autoConnect onLostConnection
name
username ***
password ***
hidden false
rootPath /
adapterOptions {}
Device
path COM3
manufacturer wch.cn
serialNumber 7&248ec8c8&0&1
pnpId USB\VID_1A86&PID_7523\7&248EC8C8&0&1
locationId Port_#0001.Hub_#0004
friendlyName USB-SERIAL CH340 (COM3)
vendorId 1A86
productId 7523
System
memFree 34976
sysname esp8266
nodename esp8266
release 2.2.0-dev(9422289)
version v1.19.1 on 2022-06-18
machine ESP module with ESP8266
uniqueId 91470b00
fsBlockSize 4096
fsBlocksTotal 763
fsBlocksFree 749
Host
OS win32 - x64
Pymakr undefined
Pymakr-Preview 2.25.2
VSCode 1.71.2

Device History at 08:35:36.471

function args time result queued at finished at failed
getFile 
[
  "//pymakr.conf"
]
 304 
{
  "py_ignore": [
    ".vscode",
    ".gitignore",
    ".git",
    "env",
    "venv"
  ],
  "name": "2022",
  "reboot_after_upload": true
}
 08:34:58.888 08:34:59.192 false
getBoardInfo 580 
{
  "memFree": 34976,
  "sysname": "esp8266",
  "nodename": "esp8266",
  "release": "2.2.0-dev(9422289)",
  "version": "v1.19.1 on 2022-06-18",
  "machine": "ESP module with ESP8266",
  "uniqueId": "91470b00",
  "fsBlockSize": 4096,
  "fsBlocksTotal": 763,
  "fsBlocksFree": 749
}
 08:34:58.308 08:34:58.888 false
getFile 
[
  "//pymakr.conf"
]
 305 
{
  "py_ignore": [
    ".vscode",
    ".gitignore",
    ".git",
    "env",
    "venv"
  ],
  "name": "2022",
  "reboot_after_upload": true
}
 08:34:58.000 08:34:58.305 false
getBoardInfo 580 
{
  "memFree": 34976,
  "sysname": "esp8266",
  "nodename": "esp8266",
  "release": "2.2.0-dev(9422289)",
  "version": "v1.19.1 on 2022-06-18",
  "machine": "ESP module with ESP8266",
  "uniqueId": "91470b00",
  "fsBlockSize": 4096,
  "fsBlocksTotal": 763,
  "fsBlocksFree": 749
}
 08:34:57.419 08:34:57.999 false
getFile 
[
  "//pymakr.conf"
]
 306 
{
  "py_ignore": [
    ".vscode",
    ".gitignore",
    ".git",
    "env",
    "venv"
  ],
  "name": "2022",
  "reboot_after_upload": true
}
 08:34:57.108 08:34:57.415 false
getBoardInfo 578 
{
  "memFree": 34976,
  "sysname": "esp8266",
  "nodename": "esp8266",
  "release": "2.2.0-dev(9422289)",
  "version": "v1.19.1 on 2022-06-18",
  "machine": "ESP module with ESP8266",
  "uniqueId": "91470b00",
  "fsBlockSize": 4096,
  "fsBlocksTotal": 763,
  "fsBlocksFree": 749
}
 08:34:56.529 08:34:57.108 false
getFile 
[
  "//pymakr.conf"
]
 310 
{
  "py_ignore": [
    ".vscode",
    ".gitignore",
    ".git",
    "env",
    "venv"
  ],
  "name": "2022",
  "reboot_after_upload": true
}
 08:34:56.216 08:34:56.526 false
getBoardInfo 579 
{
  "memFree": 34976,
  "sysname": "esp8266",
  "nodename": "esp8266",
  "release": "2.2.0-dev(9422289)",
  "version": "v1.19.1 on 2022-06-18",
  "machine": "ESP module with ESP8266",
  "uniqueId": "91470b00",
  "fsBlockSize": 4096,
  "fsBlocksTotal": 763,
  "fsBlocksFree": 749
}
 08:34:55.637 08:34:56.216 false
getFile 
[
  "//pymakr.conf"
]
 308 
{
  "py_ignore": [
    ".vscode",
    ".gitignore",
    ".git",
    "env",
    "venv"
  ],
  "name": "2022",
  "reboot_after_upload": true
}
 08:34:47.560 08:34:47.364 false
getBoardInfo 577 
{
  "memFree": 35312,
  "sysname": "esp8266",
  "nodename": "esp8266",
  "release": "2.2.0-dev(9422289)",
  "version": "v1.19.1 on 2022-06-18",
  "machine": "ESP module with%

History was truncated

jakobrosenberg commented

Hi @cristian-spiescu any folder containing a pymakr.conf file should be recognized as a project. Is this not the case for you?

I haven't seen the powershell error before. I wonder if it can be fixed settings -> Pymakr -> Terminal Profile.

cristian-spiescu commented

Thanks for your answer.

1/ my initial complaint: I don't think it's the fault of pymakr.

I observed that when the board is constantly outputting things to the console => I get that error regarding "busy". However, some improvement may be done to the tool. Because, only by using pymakr, I cannot get out of this situation. Currently I use uPyLoader to connect to board. Then use its Terminal. I reboot hard the board and I click quickly on CTRL + (I forgot) to stop the program / boot. And starting from here, I can continue the flow w/ pymakr. I want to mention that I absolutely need to kill the program soon after boot, because I use a periodic timer which is the program's "main loop". Hence trying to kill while the board is running normally, doesn't do anything, since I don't have a program running any more. Only the timer interrupts. So if pymakr would be quicker w/ the terminal, I could operate these things directly form pymakr.

2/

pymakr.conf file should be recognized as a project. Is this not the case for you?

No. I needed to recreate the project, specifying the existing folder. The "normal" version overwritten some files. But the "preview" version had the decency to ask confirmation for overwrite

3/

I haven't seen the powershell error before. I wonder if it can be fixed settings -> Pymakr -> Terminal Profile.

I will try this when I restart my micropython project. But question: does pymakr issue console commands (e.g. probably via powershell)? If yes, is there a way to monitor them?

jakobrosenberg commented

Pymakr doesn't issue console commands, but terminal access is handled through a script which is executed in your console. If Node is installed on your machine it will run something like node ./path/to/terminal.js, otherwise it will run a binary version of the terminal script. Communication with the board is handled with a library called micropython-ctl. It has some inherent issues with long running scripts and reboots so I had started work on a new driver to replace micropython-ctl.

Unfortunately Pycom went into administration on the 16th of September and I have no longer have write access to the repos.

gregbreen commented

Hi. Just trying to use my LoPy4 for the first time in a year, and my experience is exactly the same. Except I'm on Ubuntu and hence the exit of the terminal process is from bash, not Powershell (so the error is not the fault of Powershell).

gregbreen commented

Rolling back to 1.1.18 and life is good. Incidentally, Atom with 2.3.7 is also good.

VirtualWolf commented

Unfortunately Pycom went into administration on the 16th of September and I have no longer have write access to the repos.

😢

daniel-da commented

Unfortunately Pycom went into administration on the 16th of September and I have no longer have write access to the repos.

😢

So my PR will never be merged ?

😢

jakobrosenberg commented

@daniel-da I saw your amazing PR and would have loved to review and hopefully merge it. Alas, at the time of submission, I no longer had write access to the repo.

Are you on Discord by any chance?

daniel-da commented

@daniel-da I saw your amazing PR and would have loved to review and hopefully merge it. Alas, at the time of submission, I no longer had write access to the repo.

Are you on Discord by any chance?

@jakobrosenberg yes I am. But quite new on it

jakobrosenberg commented

@daniel-da feel free to add me on Discord. JakeDK#3411