sg-wireless/pymakr-vsc

config drift between serial port / serial number -> terminal wont open

reimerp opened this issue · 2 comments

I have big trouble setting up the extention. After dozens of re-installation (also of the preview version), cleaning up the user-settings file, errors like: "Cannot convert undefined or null to object"
I managed to autoconnect to my one and only device.

Now the device seems to be related to project (even not in explicitly listed in the projects pymakr.conf -- there just a project name in it), and is connected. I can also open a terminal window.
I can also run files on that device, but: Run always asks for a device as a target, since there is a one (and only one) device attached to the project, it should be a default and not ask again.

And after restarting code nothing is persisted unfortunately:
VScode tries to open a terminal with failuures: I see a terminal for a very short time but it immediately closes due to an eexception: "unable start the terminal /usr/bin/bash" Permission denied. Exitcode 1.)
In the dev console only the NotificationAlerts.ts is logged (no stacktraces)
In the Ptyhost log I found:
[warning] Shell integration cannot be enabled for executable "myhome/.nvm/versions/node/v14.15.1/bin/node" and args ["myhome/.vscode/extensions/pycom.pymakr-2.22.5/src/terminal/bin/client.js","13732","serial","/dev/ttyACM0"]

If I try to manually exec this command I get:

events.js:292
      throw er; // Unhandled 'error' event
      ^

Error: connect ECONNREFUSED 127.0.0.1:13732
    at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1146:16)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (internal/streams/destroy.js:106:8)
    at emitErrorCloseNT (internal/streams/destroy.js:74:3)
    at processTicksAndRejections (internal/process/task_queues.js:80:21) {
  errno: -111,
  code: 'ECONNREFUSED',
  syscall: 'connect',
  address: '127.0.0.1',
  port: 13732
}

And I think this is also what is shown in the terminal (before it immediatly closes)

in the user settings I find:

   "pymakr.devices.configs": {
        "12345": {
            "autoConnect": "always",
            "name": "Py 476",
            "username": "micro",
            "password": "python",
            "hidden": false,
            "rootPath": "/flash",
            "adapterOptions": {}
        },

where 12345 seems to be the serial number of my device

Even if I manually edit the User settings, remove the 40 ttyS* entries , config my device as

       "serial:///dev/ttyACM0": {
            "autoConnect": "always",
            "name": "MicroPython on STM476",
            "username": "micro",
            "password": "python",
            "hidden": true,
            "rootPath": null,
            "adapterOptions": {}
        },

, start mscode, PyMakr will not show this device, instead it shows up a new unknown one (on the same interface) but name is "unknown", so is seems a new one
If I configure it again a new entry winth the number in appended to User settings (also tons of ttyS interfaces reappear)
and I can open a console, but after restart again the issue shown above

It seems as if the device key in the settings is somehow used as a serial interface / or the serial number of the device itself. But in the latter case there is no information stored on what serial interface this device is connected.

To Reproduce
See above.

Expected behavior

  • the projects device is saved and not asked again on each upload attempt
  • the config has an entry for the serial port and maybe addionally a serial number of the device (but latter is not a functinal requirement)
  • the terminal window is restored

Desktop

  • OS: ubuntu 22.10
  • Device MicroPython v1.19.1 on 2022-06-18; NUCLEO-L476RG with STM32L476RG
  • but also Lopy1 tested w/o success
  • Pymakr v2.22.5
  • vscode 1.73.1
  • node-js v14.15.1

Just checked a local shell terminal: - restores after vscode restart.
Also switch Terminal profile to "native" (since above error is nodejs) but error remains.

The first issue can be bypassed if "Run Script Prompt" is unset -- so not an issue.