Skip to content

Running command Together uses same port #1347

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ghost opened this issue Jul 4, 2021 · 6 comments
Open

Running command Together uses same port #1347

ghost opened this issue Jul 4, 2021 · 6 comments
Assignees
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project

Comments

@ghost
Copy link

ghost commented Jul 4, 2021

Bug Report

Current behavior

when I do

arduino-cli upload --port /dev/ttyACM1 -b arduino:mbed_nano:nano33ble ./writer \
arduino-cli upload --port /dev/ttyUSB0 --fqbn esp8266:esp8266:generic ./reader

command 2 use command 1's port

Expected behavior

upload board 1
upload board 2

Environment

  • CLI version (output of arduino-cli version)
    arduino-cli alpha Version: 0.18.3-arch Commit: d710b64 Date:
  • OS and Platform
uname -a Linux ArchBox1 5.12.9-zen1-1-zen  #1 ZEN SMP PREEMPT Thu, 03 Jun 2021 11:36:07 +0000 x86_64 GNU/Linux

Additional context

Full Output

Device       : nRF52840-QIAA
Version      : Arduino Bootloader (SAM-BA extended) 2.0 [Arduino:IKXYZ]
Address      : 0x0
Pages        : 256
Page Size    : 4096 bytes
Total Size   : 1024KB
Planes       : 1
Lock Regions : 0
Locked       : none
Security     : false
Erase flash

Done in 0.001 seconds
Write 85288 bytes to flash (21 pages)
[==============================] 100% (21/21 pages)
Done in 3.308 seconds
esptool.py v3.0
Serial port /dev/ttyACM1 //wrong port
Connecting.....^C
Traceback (most recent call last):
... Suff about not begin an esp8266
KeyboardInterrupt
rm *.log;
//command used to create logs
arduino-cli upload -v -b arduino:mbed_nano:nano33ble -p /dev/ttyACM1 ./writer/ >> writer.log 2>>writer.log; arduino-cli upload -v --fqbn esp8266:esp8266:generic -p /dev/ttyUSB0 ./reader >> reader.log 2>> reader.log;

logs gist

@silvanocerza
Copy link
Contributor

Interesting. Does this happen only when one of the boards is an esp8266? 🤔

@matthijskooijman
Copy link
Collaborator

It looks a bit like esptool.py is using the wrong port somehow, I wonder how that configures the port to use. Maybe it uses some global config file instead of a commandline option for some reason?

@TravisDavis-ops, could you post verbose output of both commands? i.e. add -v to both commands?

Also, are you running both commands at the same time? Or does the problem also occur when you run them after each other?

@per1234 per1234 added status: waiting for information More information must be provided before work can proceed type: bug labels Jul 5, 2021
@ghost
Copy link
Author

ghost commented Jul 5, 2021

im running them back to back in fish using ; 's
logs
works fine with a sleep 1 in between

@silvanocerza
Copy link
Contributor

Does it happen with bash or zsh too?

@matthijskooijman
Copy link
Collaborator

I'm still not sure I understand the problem entirely. In your gist, I see a reader and writer log, I suspect this is the output you redirected to a file? What about your arduino-cli.log, is that log output from both arduino-cli runs? Looking at the output, I see a couple (more than two) of arduino-cli version 0.18.3-arch lines that, I suspect, start a new arduino-cli run?

Maybe you can show the exact command you ran, including any redirections or other info that helps us understand how your log output was made?

In any case, IIUC, the Upload port found on /dev/ttyACM0 message does come from arduino-cli, so it's not just esptool.py that is confused about the port, it's also arduino-cli itself I believe?

@ghost
Copy link
Author

ghost commented Jul 6, 2021

Made sure to clean up before running. This time grabed stderr as well.
I can leave off the port on the second command and it still happens.
happens in bash as well.

*update
It doesnt happen with my mega

@fstasi fstasi removed the type: bug label Sep 16, 2021
@rsora rsora added the type: imperfection Perceived defect in any part of project label Sep 22, 2021
@per1234 per1234 added the topic: code Related to content of the project itself label Mar 7, 2022
@umbynos umbynos removed the status: waiting for information More information must be provided before work can proceed label Dec 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: code Related to content of the project itself type: imperfection Perceived defect in any part of project
Projects
None yet
Development

No branches or pull requests

7 participants