I'm attaching a screenshot. Not in the screenshot, but verified, is that the serial monitor, and my teensy, are still very much active. As I stated in the title, after some random number of uploads, IDE 2.0.2 just greys out the upload menu. Sometimes this happens after one compile, sometimes several, as of now I have detected no definitive trigger that allows a reliable reproduction.
Closing and restarting the program fixes this condition, every time.
I have never seen this happen with previous IDE 2.0 versions, going back to the RC ones.
What do you have selected in the Tools > USB Type menu?
After you experience the problem, is there a port selected in the Tools > Port menu?
If your board is producing multiple types of ports (e.g., a "serial port" and a "teensy port"), which of the ports do you have selected in the Tools > Port menu?
I see that the Sketch > Upload menu item is disabled when the port of the board disappears during upload (which is expected for the boards with native USB capability), then enabled again at the end of the upload.
I did find a somewhat contrived procedure that will produce the condition:
Select Sketch > Upload from the Arduino IDE menus.
Unplug the USB cable from the board.
Wait for the upload to fail.
The Sketch > Upload menu item remains disabled even after the upload fails.
I found this does not occur with the boards like Uno, Mega, Nano that don't have a native USB capability. I was able to reproduce it with all the native USB boards I tried: Teensy 4.1, Leonardo, MKR Zero.
The problem does not occur if I disconnect the board when the flashing stage of the upload operation has started.
The Sketch > Upload menu item is enabled as soon as I plug the USB cable of the board back in.
The question is: what normal use case could produce the same conditions? I tried some experiments like doing a double reset on the MKR board to put it into bootloader mode before the upload and uploading a sketch that causes the board to not have a CDC serial port after the upload. Neither of these caused the bug to occur.
I opened the program, did a single successful upload and it did it (but sometimes it takes several uploads before it shows up). Screenshot will be below. On this I captured the port menu, which prevented me from putting the Sketch menu in the same image. I dragged it down to include the serial port monitor, the data showing in that window was a response to a command I sent to the Teensy (to dump the configs I have in the program).
When the program gets uploaded, the Teensy loader seems to take control, program and then reset the board. But 2.0.2 seems (sometimes) to not think a board is connected.
Wes
I had to split the image into two halves to get it to upload here:
I uncovered one additional happenstance on this. When it happens, the upload sequence on the teensy uploader seems to be "normal", and after it completes, in the lower right side is a box that opens saying "Uploading" (this comes after "Compiling").
Normally the IDE box is only there until immediately after the teensy loader finishes it's own upload progress box. However, if the IDE shows that box for a longer time period, the "Upload" menu-item is disabled.
This is becoming a PITA here. In reviewing the screens to type this message I got three consecutive failures in a row. This is an impediment to the tweak, upload and test cycle, because it ends up becoming a tweak, upload, test, close IDE, start IDE cycle. My computer is not slow, but the startup from cold is not close to apparently instant (like for simple apps).
Wes
Additionally, I want to say this was not an issue on 2.0.1. I suspect the "timing" fixes on the former problem where "Compile" refused to work and said it wasn't connected is related.
I had the same phenomen when trying to upload to an ESP32 Node-MCU
Upload was not possible
I veryfied that COM-Port 5 is available with IDE 1.8.19 works very fine
So I terminated IDE 1.8.19 and started IDE 2.0.2 new and then upload was not possible
It is very clumsy to collect screenshots of what do I know what might be important.
Does the new IDE 2.0 have some kind of
activate verbose debug-output logging into a file
that tells evevything but the sourcecode into a single textfile?
Hi @StefanL38. Arduino IDE 2.x always generates log files. They are located under this folder:
C:\Users\<user name>\AppData\Roaming\Arduino IDE\
If looking for it with your file browser or command line, note that the C:\Users\<user name>\AppData\ folder is hidden by default. On Windows "File Explorer", you can make it visible by opening the "View" menu, then checking the box next to "☐ Hidden items".
Other than the addition of timestamps, the contents of the log files are the same as what you see printed in the terminal when you start Arduino IDE 2.x from the command line. I personally find the approach of monitoring logs from the command line more useful because I can easily see exactly which logs are associated with a given action in the IDE. I often clear the terminal before performing an action of interest in the IDE so that it becomes more clear. But some may prefer the log files.
It is also possible to enable increased verbosity in the logs by doing the following:
Press the Ctrl+Shift+P keyboard shortcut (Command+Shift+P for macOS users) to open the "Command Palette".
Select the "Preferences: Open Settings (UI)" command from the menu.
A "Preferences" tab will now open in the Arduino IDE main panel. In the "Search Settings" field, type arduino.cli.daemon.debug
Check the checkbox under the "Arduino › Cli: Daemon: Debug" setting.
Restart Arduino IDE.
Unfortunately this adds a large quantity of additional content to the logs. The logs from a short session will be in the tens of megabytes. For this reason, the logging to terminal approach is not suitable when the daemon logs are enabled because they will exceed the terminal buffer and may even result in performance problems if the terminal is unable to handle the huge amount of output. It will be better to start Arduino IDE, perform whatever actions of interest, close all Arduino IDE windows (File > Quit), then open the log file in a capable text editor.
2022-11-21 09:45:12 daemon INFO e[36mINFOe[0m[0568] sending command e[36mcommande[0m="OPEN 127.0.0.1:55622 COM4" e[36mmonitore[0m=serial-monitor
2022-11-21 09:45:12 daemon INFO e[36mINFOe[0m[0568] received message e[36merrore[0m=true e[36mevent_typee[0m=open e[36mmessagee[0m="Serial port not found" e[36mmonitore[0m=serial-monitor
e[36mINFOe[0m[0568] sending command e[36mcommande[0m=QUIT e[36mmonitore[0m=serial-monitor
2022-11-21 09:45:12 daemon INFO e[36mINFOe[0m[0568] received message e[36merrore[0m=false e[36mevent_typee[0m=quit e[36mmessagee[0m=OK e[36mmonitore[0m=serial-monitor
e[36mINFOe[0m[0568] Killing monitor process e[36mmonitore[0m=serial-monitor
2022-11-21 09:45:12 daemon INFO e[31mERROe[0m[0568] Sent kill signal e[31merrore[0m="TerminateProcess: Access is denied." e[31mmonitore[0m=serial-monitor
2022-11-21 09:45:12 daemon INFO e[31mERROe[0m[0568] stopped decode loop: EOF e[31mmonitore[0m=serial-monitor
2022-11-21 09:45:12 daemon INFO e[36mINFOe[0m[0568] Monitor process killed e[36mmonitore[0m=serial-monitor
2022-11-21 09:45:12 monitor-service ERROR Error: 2 UNKNOWN: Port monitor error: command 'open' failed: Serial port not found
at Object.callErrorFromStatus (C:\Program Files\Arduino IDE\resources\app\node_modules\@grpc\grpc-js\build\src\call.js:31:26)
at Object.onReceiveStatus (C:\Program Files\Arduino IDE\resources\app\node_modules\@grpc\grpc-js\build\src\client.js:409:49)
at Object.onReceiveStatus (C:\Program Files\Arduino IDE\resources\app\node_modules\@grpc\grpc-js\build\src\client-interceptors.js:328:181)
at C:\Program Files\Arduino IDE\resources\app\node_modules\@grpc\grpc-js\build\src\call-stream.js:187:78
at processTicksAndRejections (node:internal/process/task_queues:78:11)
2022-11-21 09:45:12 monitor-service INFO monitor to COM4 using serial closed by server
However, I see that in my logs even after a fully successful upload operation to a Teensy board, so it seems more likely to be a "red herring".
Does the problem only occur when you have Serial Monitor open while uploading?
I never tried closing the serial monitor. I use that feature a lot to tweak the running program parameters.
One thing that seems to be relevant is that closing the uploader window before clicking upload appears to make it less frequent... but it is as temperamental as any ordinary billionaire running a social media company.
I will test that and see.
Interesting question about the serial monitor...
My preliminary results after a dozen or so uploads is that without the Serial Monitor open, this does not happen.
I will maybe just use coolterm for now and leave the serial monitor off, although for understandable reasons uploads fail if I stay connected with the serial port locked. One more ball to keep in the air.
I believe there may be some connection between how soon the serial port is opened on the device and whether the Upload menu-item gets locked.
Thanks for checking. This is definitely important information. Finding the specific conditions the fault occurs under would be very helpful for the resolution of the bug.
Please let me know if either of you experience the fault when uploading without Serial Monitor open.
Note: I have seen issues, where it might forget which connection I am using for the Teensy, and I need to reselect one. Although, this hits me more with the Serial Monitor than with uploads.
But I have not run into the case where I have to exit the Arduino IDE to get it to work again. I have exited the Teensy app, if I have into issues for uploads.
I also should mention that the majority of the time, I don't use the Arduino Serial monitor, and instead use TyCommander for the monitor. Note: If I have this open and Serial on, uploads will fail as TyCommander is connected... In this case I will often then just push the program button on the Teensy and it will reprogram and continue.
Will post more information up on the Teensy thread.
Why this problem happens with "Serial ports" selected, and how to fix it, I do not (yet) know. But hopefully just knowing the problem can be solved by clicking "teensy ports" helps everyone who's currently suffering from this issue.
To explain just a bit further, Teensy provides pluggable discovery and pluggable monitor utilities specifically designed to work with Teensy. Arduino IDE 2.0.2 comes with its own discovery & monitor utilities meant to work with all serial ports, and with certain network communication (eg, Arduino Yun).
When Teensy appears to your PC as a serial device, it gets detected by both Teensy's pluggable discovery utility and by Arduino's discovery for all serial devices. Currently the Arduino IDE doesn't have any way to know when 2 different discovery utilities have detected the same physical hardware. Maybe someday in the future it will, but since the version 1 pluggable discovery spec doesn't provide any mechanism for this, it seems unlikely.
When you select "teensy ports", all communication with Teensy is done with PJRC-provided code. Arduino IDE2's serial monitor communicates with the Teensy pluggable monitor utility (using localhost communication), which in turn talks to Teensy. Of course, uploading is done by running utilities which communicate with Teensy Loader.
When to select "Serial ports", the serial monitor communication is done with Arduino's monitor utility. But uploading to Teensy is still done by running a PJRC-written utility which communicates your .HEX file to Teensy Loader and then tries to ask Teensy to automatically go into bootloader mode. Why these aren't playing nice together and the Upload menu gets disabled is still a mystery to me. I hope to learn more soon.
When you use "teensy ports", you'll see the port name is not a COM port. It's a string like "usb:0/1A0007/0/1/3" on Windows or "usb:1/1-1/1-1.1/1-1.1.3" on Linux or "usb:52130000" on MacOS. These strings represent the physical USB location on your PC. If you plug another USB hub between your computer and Teensy, you'll see the info gets longer, and as you plug into different physical ports on that hub, you'll see the number change to represent the physical location. Teensy uses this format because we support many different USB device modes (in the Tools > USB Type menu) and a good number of them do not have any serial port. When you upload new programs to your Teensy which turn it into new USB device types, the port selection stays the same because it encodes the physical USB controller-hubs-port location rather than protocol-specific details. In those non-serial modes, Teensy implements a HID interface to emulate serial, so you can still use Serial.print() and communicate with the serial monitor. Teensy's pluggable monitor utility "knows" all the USB types Teensy supports and automatically uses the correct type of communication so the serial monitor will "just work".
Maybe that's more than anyone really wanted to know about Teensy's PC-side software, and whether it helps to understand what's going wrong with the Upload menu disable is questionable. But if you're wondering why there are 2 redundant things to select in the Tools > Ports menu, hopefully this explains why.
Thanks for sharing that valuable information pjrc!
I managed to find the conditions under which I can reproduce the fault. I am able to reproduce it even when uploading to non-Teensy boards, so I think the fault is not directly related to the situation with the board having both a teensy protocol and a serial protocol port.
I submitted a formal bug report to the developers here:
I thought I would mention, that yesterday, I ran into this issue with upload grayed out,
on an Arduino Nano 33 IoT where an upload failed and left it disabled.
If looking for it with your file browser or command line, note that the 
