Serial port and board type don't "stick" after uploading to Pico/Pico W

[daniloc]

Describe the problem

When uploading code to a Pico or Pico W, the IDE does not retain the selected board type or serial port, selecting /dev/cu.Bluetooth-Incoming-Port.

When the board boots, its port is labeled "Generic RP2040."

On each upload it's necessary to re-select the port (for serial monitor) and set the board type again (to upload).

To reproduce

1. Use Arduino-Pico for initial programming of a Pico board
2. Select board and port and upload again

Screen.Recording.2022-07-23.at.9.39.27.PM.mov

Expected behavior

When the board and port come back online, the port should be re-selected with the previous board definition.

Arduino IDE version

2.0.0-rc9

Operating system

macOS

Operating system version

12.4

Additional context

I suspect this is an artifact of the disk-based programming of RP2040 boards, but don't know much beyond that. The port issue also appears when using the official Arduino Core, although in that case it does seem to remember the board type.

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the latest nightly build
• My report contains all necessary details

[per1234]

Hi @daniloc. Thanks for your report.

Please try this and then comment here to tell us what the result was:

1. Select Tools > Port > /dev/cu.Bluetooth-Incoming-Port from the Arduino IDE menus.
2. Select Tools > Boards > Arduino AVR Boards > Arduino Nano from the Arduino IDE menus.
3. Select the port of your Pico board from the Tools > Port menu.
4. Select the board for your Pico board from the Tools > Board menu.
5. Select Sketch > Upload from the Arduino IDE menus.
6. Wait for the upload to finish successfully.
7. Open the "Board Selector" menu from the Arduino IDE toolbar.

Is the correct board and port still selected after following the above instructions?

---

My suspicion is this is the same as #180

---

Other reports of problems caused by the naïve "automagical" port/board handling system of Arduino IDE 2.x:

• Port selection of Portenta H7 (M4 Core) is lost on every upload #43
• Adafruit Trinket M0 won't persist port #82
• Serial port re-enumerates after upload with SAMD boards (probably other USB native) #287
• Port changes on native USB upload when two ports are associated with the selected board name #710

[daniloc]

Thank you for the reply, @per1234! I have followed your instructions a few times to be certain, from fresh launches of the IDE. Here is what I observe:

With Arduino-Pico

It's half-way to better.

The board selector DOES NOT gobble up the Bluetooth port like it has in previous sessions, but nor does it select the correct port after upload. The board selection reverts to Generic RP2040 after upload as well.

With Arduino's official distribution

Everything works as it should, across multiple uploads.

---

Appreciate any context you can share about this behavior, @per1234. Is there some special-case behavior behind the scenes triggered by selecting the Nano board that other boards haven't been opted into?

Also, does this outcome suggest a bug in the Arduino-Pico code? Any information you could share to help me open an issue in that project, if necessary, would be appreciated, as aside from this hiccup I'm finding it meeting my needs perfectly.

[per1234]

The board selector DOES NOT gobble up the Bluetooth port like it has in previous sessions, but nor does it select the correct port after upload. The board selection reverts to Generic RP2040 after upload as well.

This bug is tracked at #82

If you look at the board definitions for the "Raspberry Pi Pico W" and "Generic RP2040" boards in the platform's boards.txt file, you can see they both use the same VID/PID pair, which is the required conditions for #82:

https://raw.githubusercontent.com/earlephilhower/arduino-pico/2.3.3/boards.txt

rpipicow.vid.0=0x2e8a
rpipicow.pid.0=0xf00a

generic.vid.0=0x2e8a
generic.pid.0=0xf00a

Is there some special-case behavior behind the scenes triggered by selecting the Nano board that other boards haven't been opted into?

No. I picked that board arbitrarily.

When you select a port and a board, the Arduino IDE remembers that association. It is convenient in some cases, but it is very inconvenient when you accidentally make an unintentional association.

My instructions simply caused the "Arduino Nano" board selection to be associated with the /dev/cu.Bluetooth-Incoming-Port port instead of the "Raspberry Pi Pico W" board selection.

With Arduino's official distribution

Everything works as it should, across multiple uploads.

This is because the VID/PID pair used by Arduino is only associated with a single board definition, so it is not affected by #82:

https://github.com/arduino/ArduinoCore-mbed/blob/3.2.0/boards.txt#L405-L406

pico.vid.0=0x2e8a
pico.pid.0=0x00C0

does this outcome suggest a bug in the Arduino-Pico code?

I wouldn't say so. There is nothing in the Arduino Platform Specification that prohibits multiple board definitions from using the same identifiers, and such a prohibition would be unreasonable anyway because it is not only a matter of requiring the boards to have a unique identifier within the platform, but also to have a unique identifier within the entire ecosystem of thousands of board definitions maintained (or not maintained) by dozens of entities who would never and could never coordinate on such a thing.

No, it is simply a well intentioned but naïvely designed "feature" of the Arduino IDE that probably sounded good at first, but doesn't work in real world conditions.

---

It is best to have only a single issue per subject so we can consolidate all relevant discussion to one place. Since we are already tracking these bugs at #82 and #180, I'll go ahead and close this in favor of the other.

If you end up with additional information to share, feel free to comment in the other thread.