Failed to open the sesrial port /dev/ttyACM1

[chaoyangnz]

Type: Bug Report

Describe the bug

• OS and Version: Ubuntu 22
• VS Code Version: 1.83.1
• Serial Monitor Extension Version: 0.10.231005001
• Target embedded device: CH32V103
• Other extensions you installed (and if the issue persists after disabling them):
• A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

I can connect with other native serial terminal: minicom, cutecom, and a terminal I wrote in Go. I looked into the logs, it shows Serial monitor:

2023-10-12T08:07:54.025Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"portService","type":"openSerialPort","kind":"request","messageId":9,"payload":{"port":{"portName":"/dev/ttyACM1","friendlyName":"wch.cn","vid":"1a86","pid":"8010"},"baudRate":115200,"dtr":true,"rts":true}}
2023-10-12T08:07:54.036Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"portService","type":"openSerialPort","kind":"exception","messageId":9,"payload":{"message":"Error: Broken pipe, cannot set","stack":"Error: Error: Broken pipe, cannot set","vslsStack":[]}}
2023-10-12T08:07:54.039Z [debug] [vscode-serial-monitor.monitor] Failed to open port /dev/ttyACM1 due to "[object Object]"

Expected behavior

Code sample and logs

• Code sample
• launch.json

Screenshots

Additional context

[gcampbell-msft]

@chaoyangnz Thanks for letting us know about this issue.

Could you possibly try a different board and let us know if this issue is widespread or if it's something specifically with this board? If it's specifically with one type of board, then it could still be a number of different things, but it narrows it down some to the firmware on the embedded device, or the specific settings that device needs.

Any information would be great!

[chaoyangnz]

Yes, I tried a different board, it worked for other boards. seems that only happened in the specific board.

[atomsmith]

@gcampbell-msft I can reproduce this issue easily, using extension v0.11.0 under Ubuntu 22.04, with any of the following Atmel/Microchip eval boards:

• SAM D21 Xplained Pro
• SAM E70 Xplained
• SAM V71 Xplained Ultra

I can also reproduce this when Serial Monitor is the only enabled extension.

Like @chaoyangnz mentioned, minicom can open the serial port without issue. Unlike his report, however, I did not find the "failed to open port" message in the Serial Monitor's extension log file.

[gcampbell-msft]

@atomsmith, as a way to test, could you test if you see this issue with this simple cli for the underlying serialport package we use? It would help us identify if it's an issue with the underlying library or with something on our side.

Thanks!

[atomsmith]

@gcampbell-msft Using the "npx" method of execution, the serialport package can successfully open /dev/ttyACM0 from one of the Atmel boards.

However, if I press "Start Monitoring" in the Serial Monitor extension (which results in the "Failed to open" message), serialport fails with the following message until I exit VS Code:

Opening serial port: /dev/ttyACM0 echo: true
Error [Error: Error Resource temporarily unavailable Cannot lock port]

Minicom does not seem to be affected by this lock; it can open the port at any time, even if serialport simultaneously has the port open.

[gcampbell-msft]

@atomsmith Could you test a variety of the RTS/DTR settings in the Serial Monitor when you press "Start Monitoring" and let me know what happens with the various settings?

[atomsmith]

@gcampbell-msft It fails to open under all four combinations of the RTS and DTR settings.

[gcampbell-msft]

@atomsmith Since I unfortunately don't have the hardware available that is mentioned above, I'm not able to directly reproduce or test this, however, I do have a suspicion of what the issue might be.

If you're able and willing, some testing help would be great.

I have a very simple node project, that if you're willing to play with, could help us diagnose if this is in fact an issue on the serialport library.

If you could unzip this: test.zip, and then follow the following steps:

1. You'll need node + npm installed.
2. Run npm install in the directory you extracted (the directory of the package.json).
3. Run npm run build.
4. From the directory of the package.json, run node dist\serialport.js. Depending on what port your board is on (find on the device manager), you may need to modify the code in serialport.ts on line 3, and then run step 3 again. Does it manage to open the port successfully? Feel free to add console.log statements where necessary (maybe line 10, etc) to confirm whether it successfully opens the port.

Then, I'm curious to know if you uncomment line 10, the serialPort.set... line, and re-run the necessary steps to build and open, if it's still able to open the serial port.

Again, I understand if you don't have the time to investigate this, but it would be very helpful since I don't have the hardware to be able to reproduce this issue that seems specific to the aforementioned boards.

Thanks!

[atomsmith]

@gcampbell-msft Thanks for the clear directions. After I modified the code to open /dev/ttyACM0, it could open the port and display comm traffic from my board. When I uncommented line 10, the following fatal error occurred:

node:internal/process/promises:279
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: Error: Broken pipe, cannot set
Emitted 'error' event on SerialPort instance at:
    at SerialPort._error (/path/to/node_modules/@serialport/stream/dist/index.js:79:18)
    at /path/to/node_modules/@serialport/stream/dist/index.js:268:25

[gcampbell-msft]

@atomsmith Thanks for testing! I believe this is actually an external issue on the node serial-port: https://github.com/serialport/node-serialport/issues/2312, https://github.com/serialport/node-serialport/issues/2636.

I'm going to mark this as external. However, we may want to do something where we allow for disabling of calling this method so that you can at least open the monitoring, though if you desire to set certain flags for DTR and RTS, it might not be possible due to the external issues.

[ToonVanEyck]

I am also experiencing this issue with a STM32F103C based DAPLink (from Aliexpress):

I can use the serial port using this:

as a way to test, could you test if you see this issue with this simple cli for the underlying serialport package we use? It would help us identify if it's an issue with the underlying library or with something on our side.

Log:

2024-03-29T09:43:54.454Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorHost","type":"updateSettings","kind":"request","messageId":14,"payload":{"terminalMode":false}}
2024-03-29T09:43:54.455Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorHost","type":"setContext","kind":"request","messageId":16,"payload":{"id":"isActivelyMonitoring","value":true}}
2024-03-29T09:43:54.462Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"portService","type":"openSerialPort","kind":"request","messageId":18,"payload":{"port":{"portName":"/dev/ttyACM0","friendlyName":"jixin.pro","vid":"c251","pid":"f001"},"baudRate":115200,"dtr":true,"rts":true}}
2024-03-29T09:43:54.467Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorWebview","type":"isActivelyMonitoring","kind":"request","messageId":1}
2024-03-29T09:43:54.467Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorWebview","type":"isActivelyMonitoring","kind":"response","messageId":1,"payload":true}
2024-03-29T09:43:54.469Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorHost","type":"updateSettings","kind":"response","messageId":14}
2024-03-29T09:43:54.469Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorHost","type":"setContext","kind":"response","messageId":16}
2024-03-29T09:43:54.476Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"portService","type":"openSerialPort","kind":"exception","messageId":18,"payload":{"message":"Error: Broken pipe, cannot set","stack":"Error: Error: Broken pipe, cannot set"}}
2024-03-29T09:43:54.476Z [debug] [vscode-serial-monitor.monitor] Failed to open port /dev/ttyACM0 due to "[object Object]"
2024-03-29T09:43:54.476Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorHost","type":"updateSettings","kind":"request","messageId":26,"payload":{"terminalMode":false}}
2024-03-29T09:43:54.476Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorHost","type":"setContext","kind":"request","messageId":28,"payload":{"id":"isActivelyMonitoring","value":false}}
2024-03-29T09:43:54.525Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorWebview","type":"isActivelyMonitoring","kind":"request","messageId":2}
2024-03-29T09:43:54.525Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview -> host]: {"service":"monitorWebview","type":"isActivelyMonitoring","kind":"response","messageId":2,"payload":false}
2024-03-29T09:43:54.525Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorHost","type":"updateSettings","kind":"response","messageId":26}
2024-03-29T09:43:54.532Z [debug] [vscode-serial-monitor.monitor] VsCodeHostAdapter [webview <- host]: {"service":"monitorHost","type":"setContext","kind":"response","messageId":28}

Do you think this is related to the same issue?

Regards, Toon

[gcampbell-msft]

@ToonVanEyck Yes, I think it's almost certainly the same issue.

Just for my information, what operating system are you on?

[ToonVanEyck]

Just for my information, what operating system are you on?

I'm on a devcontainer using the WSL backend.

[gcampbell-msft]

@ToonVanEyck @atomsmith @chaoyangnz

Because I've noticed that the bug here on the external dependency: https://github.com/serialport/node-serialport/issues/2636, is only happening on linux, I wonder if a quick way to unblock you all is to only call this method if we're not on linux.

Could you all manually switch the extension of this zip to .vsix, install it, and test to see if this fixes your issue? vscode-serial-monitor.zip

[tapir]

sorry but how can I install a vsix?

[tapir]

Ok I managed to unzip and manually install. Good news it works!!

[pkoevesdi]

I can confirm: I had the same problem - no connection. With the extension from the comment https://github.com/microsoft/vscode-serial-monitor/issues/142#issuecomment-2034641134142#issuecomment-2034641134 I can at least connect, and also I can send, but I don't receive anything. Is this a different issue or do I miss something?

[ToonVanEyck]

I can confirm @pkoevesdi's results. I can connect and transmit with the extension from the comment. But i cannot receive data.

[gcampbell-msft]

@tapir @pkoevesdi @ToonVanEyck Could you all test the steps from this comment? https://github.com/microsoft/vscode-serial-monitor/issues/142#issuecomment-1864644326

I apologize that I'm needing your all's help for debugging, but since I don't have the required hardware, but if you could use that sample program it would be good to understand what might be going on. While testing that program, if you modify line 3, you could test different settings of: rtscts, xon, xoff, etc. This will help me understand what the issue is that's happening.

[pkoevesdi]

Ok, I tried it, but it doesn't work. I put my port "/dev/ttyACM0" in line 3, ran npm run build and then node dist/serialport.js, but nothing happens, the program seems stuck. I can't even cancel it with Ctrl+C. Then I started over, deleted the directory, unpacked the zip file newly, now when I run npm install (step 2), I get the following:

/usr/lib/node_modules/npm/lib/es6/validate-engines.js:31
    throw err
    ^

Error: ENOENT: no such file or directory, uv_cwd
    at process.wrappedCwd (node:internal/bootstrap/switches/does_own_process_state:126:28)
    at process.cwd (/usr/lib/node_modules/npm/node_modules/graceful-fs/polyfills.js:10:19)
    at new Config (/usr/lib/node_modules/npm/node_modules/@npmcli/config/lib/index.js:96:19)
    at new Npm (/usr/lib/node_modules/npm/lib/npm.js:77:19)
    at module.exports (/usr/lib/node_modules/npm/lib/cli-entry.js:17:15)
    at module.exports (/usr/lib/node_modules/npm/lib/es6/validate-engines.js:39:10)
    at module.exports (/usr/lib/node_modules/npm/lib/cli.js:4:31)
    at Object.<anonymous> (/usr/lib/node_modules/npm/bin/npm-cli.js:2:25)
    at Module._compile (node:internal/modules/cjs/loader:1364:14)
    at Module._extensions..js (node:internal/modules/cjs/loader:1422:10) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'uv_cwd'
}

Node.js v18.20.1

This is where my time budget ends for this for now, sorry.

[ToonVanEyck]

I was able to run the application. When I uncomment line 10, the application crashes. Regardless off the values of dtr and crs (true/false)

node ➜ /workspaces/mscvs_test $ node dist/serialport.js
node:internal/process/promises:289
            triggerUncaughtException(err, true /* fromPromise */);
            ^

Error: Error: Broken pipe, cannot set
Emitted 'error' event on SerialPort instance at:
    at SerialPort._error (/workspaces/mscvs_test/node_modules/@serialport/stream/dist/index.js:79:18)
    at /workspaces/mscvs_test/node_modules/@serialport/stream/dist/index.js:268:25

Node.js v20.12.0

I'm unsure how to test for xon/xoff. Nor do I know how to test for dtr/crs in line 3.

I modified the code to have it echo the received data:

 serialPort.on("data", (data) => {
    const text: string = data.toString();
    process.stdout.write(text);
    serialPort.write(text); // <- added this line: echo data
});

This allowed me to echo any received data. This works (with line 10 commented).

[gcampbell-msft]

Interesting, as a sanity check, here is a vsix that has removed our use of the .set call fully, to see if this possibly has other causes or implications. Could you let me know if this works for you?

Since the above didn't work, I'm curious if there may be other complications to consider.

Again, I appreciate your patience and willingness to test. vscode-serial-monitor.zip

[pkoevesdi]

Hmm, strange, with this zip it worked. Then I uninstalled it, and installed the current stable from the market - and i work too, suddenly! I have no idea, what changed.

[pkoevesdi]

With the prerelase- version, it doesn't work again, with the durrent release version it works.

[gcampbell-msft]

@pkoevesdi To confirm, you're saying that it consistently works on the official release, but it consistently does not work on the pre-release?

If this is the case, it'd be great if you could narrow down to what version of the pre-release it stopped working. You can install specific versions of the extension by the following:

[ToonVanEyck]

For me the normal release as well as the zip are "working", at least I can connect to the device, but I can only transmit an not receive.

Another clue might be that I don't get the ---- Opened the serial port /dev/ttyACM0 ---- message but I do get the ---- Closed the serial port /dev/ttyACM0 ---- message.

I also tested som different prerelease versions for you. Tested prerelease versions:

• 0.11.240404001 --> does not work
• 0.11.240217001 --> does not work
• 0.11.240106001 --> does not work
• 0.11.231206001 --> does not work
• 0.11.0 --> "works" (TX only)

[ToonVanEyck]

I also have a device that doesn't work (only TX and no "opened" message) with the current release. But it does fully work with te prerelease. Then when I disconnect and try to connect to another device I get **** Failed to open the serial port /dev/ttyACM0 ****. When I now try to reconnect to the originally working device, I get: **** Failed to open the serial port /dev/ttyACM1 ****

[pkoevesdi]

I can confirm: Ist consistenly works with the current release, and not with the next one after that. I tried just a few further even after that, they didn'twork either.

[gcampbell-msft]

@ToonVanEyck @pkoevesdi Is there any version of the extension that works for both transmitting and receiving? Also, in terms of receiving, I assume that you've tried different versions of data bits, stop bits, and parity bits? This could affect whether data gets correctly sent and received.

[pkoevesdi]

No, I compared only the versions with each's standard settings, with which it works in the current release, and not on the next one after that. As written, days ago it didn't work with the then-current release neither, not sure if it was updated in the meantime. Sorry, if I'm not very helpful...

[gcampbell-msft]

@pkoevesdi No worries at all! I very much appreciate your help, I've got this on my backlog to continually investigate, and your help has been great since I don't have all the possible combinations of hardware + machine that people have.

[ToonVanEyck]

Does this fixed-pending-release mean you found something?

[gcampbell-msft]

@ToonVanEyck, yes, we're hitting some pipeline issues, but as soon as they are resolved a pre-release version should be released that should fix these issues on linux. Thanks.

[ungerer-ricardo]

Hi,

I've also had this issue, but I had it in /dev/ttyACM0.

But version 0.11.240501001 seems to have solved it.

[ranger81]

Hi, I can confirm as well, pre-release v0.11.240501001 also solved the issue for me.

[saperlot]

HI i also had the same issues, with the released Version, now on v0.11.240618002 (pre-release) it works.

[ToonVanEyck]

Also works for me :)