I am pretty new to Arduino.
My programming skills should be sufficient to make some progress with the actual coding, but I haven't got that far yet.
Tried to read forum posts and guides according to instructions before posting, but I am kind of stuck so here I am.
Hooked up an MKR NB1500 and face issues with the IDE and USB ports when uploading a sketch.
From what I read it is normal that the behavior of the Arduino USB port causes the COM number to change along the process. I can see in Windows 7 Devmgr that it alters between COM36 and COM37.
But I find it quite annoying that the IDE loses connectivity to the board every now and then, then I have to open the pulldown list and re-select it.
For me a normal scenario includes a fair amount of trial and error, and serial terminal output is crucial to be able to se how far my program gets.
Compiling and transferring a sketch to the board mostly goes ok, until text "CPU Reset" is displayed. I guess that means the board reboots and loads my code.
But serial terminal frequently complains "Not connected. Select a board and a port..." and I haven't found how to recover from this. Some times closing the IDE and unplugging/replugging USB does the trick.
In the forum I saw posts recommending closing serial terminal before uploading sketch and subsequently opening it. But then any serial output prior to doing so will lose my attention...should't it be possible to see all serial terminal output, starting from that in the Setup loop?
To sum it up I find this behaviour quite annoying, too much of my time and attention is allocated to bitching with USB ports, reselecting the board, unplugging USB cable and turning on/off the serial terminal.
I wish this was seamless, so I could concentrate on the programing task instead..
At this point I don't think 3rd party IDEs/editors is the way to go..that must eventually come at a later point of time.
From the description that you gave about the changing COM ports, the MKR NB1500 has native USB. If you do not want to miss data, your code in setup() should contain the line while(!Serial) before the first print happens.
Thank you sterretje.
But can't that possibly stall the program execution forever, in case no termninal connects?
Regarding my initial post:
I'm willing to do whatever it takes to make this function, be it adding another USB card in my computer, strictly following a procedure or other measures.
To get further I need this to be consistent, i.e. that I know which steps to go through druing the dev phase, and which symptoms means what.
Now, to me it is totally inconsistent.
BTW, is it possible somehow to hook up another serial terminal, separate from the IDE? I could go RS-232 if that is what it takes.
You can add a timeout in the while(!Serial). A simple way would be
while (!Serial || millis < 5000) ;
You will also have to cater for the fact that you can disconnect after being connected. That can bring your sketch to a near grinding halt. You can use Serial.availableForWrite() to check if there is enough space in the output buffer to send the data.
An intermittent connection such as you describe is not normal, though my experience is limited to mega/uno/nano boards. Are you sure you don't have a bad cable or connector, or possibly a bad connector solder joint, or even an unstable power supply(we have no info on your overall setup).
ASUS P8Z77 Mobo, onboard USB3, stock USB cable.
Windows 7.
No soldering, no external power supply.
Of course I can swap USB cable.
I have a feeling that the problem is related to the changing com numbers (indicated by Windows ding-dong sound) when transferring sketch to the MKR. That's when I lose connection to the board, and when the serial term starts complaining.
Could it be that some types of USB ports behave better than others?
Certainly, some do and some don't, usually when plugging into different ports on the same PC. For example, some(usually old or cheap clone) will be COM X when plugged into one USB port, but COM Y when plugged into another; others actually can get a different COM assignment even in the same port. But I'll step back now, as I have no knowledge of this in the Arduino context.
When you select the COM port (COM36 in your case) and open the serial monitor, that COM port is what serial monitor uses.
When you do an upload, the board is reset to invoke the bootloader and the bootloader is on a different COM port (COM37); hence the serial monitor complains as the original COM port no longer exists
Once the code is loaded, the bootloader hands control to your sketch and you will (usually) get the original COM port back.
That is the beautiful theory and it usually works. I can't remember that I have had issues with it in IDE2.0 when using 32U4 based boards.
It might be that Windows has different thoughts and the COM port changes after the control is given back to the sketch by the bootloader; in that case the serial monitor has no idea about that and you end up with the error that you get.
To help further:
As far as I can determine, you're using IDE2.0; which version exactly? Please confirm.
You can monitor the process in Windows device manager. Is the sequence COM36 at start, COM37 during upload, and COM36 again after that?
There is / was a known issue like what you describe in IDE2.0; I do not know if it's solved or still outstanding and can't research that now.
You can use IDE 1.8.19; it does not have the problem to my knowledge (except when Windows buggers it up).
I can kind-of reproduce the issue on a Leonardo. As mentioned, I don't have the problem after upload but when reseting the board manually occasionally the IDE does not see the switch-back by the operating system to the original port. In my case it goes from COM20 to COM21 and it never goes back in the IDE2.0 but it goes back in Windows device manager.
I was using latest, 2.0.1
Now I uninstalled, rebooted and installed 1.8.19. Finally, for the first time my setup appears to display some kind of consistency, i.e. I am able to do several consecutive compiles/transfers/serial terminal sessions without things being messed up.
Now the MKR shows up at COM36 initially, turns to COM37 upon sketch transfer and then reverts to COM36. I think it was the other way around with IDE 2.0.1.
With 1.8.19 serial monitor in separate window (good thing!) stays up and reconnects upon sketch update / new transfer
To me it looks like the bug is still around in 2.0.1, unusable for me...
Would love to hear how other 2.0.1 users (must be thousands of them out there?) work around this bug and get things done
Done
Now the board is also available on COM36 after an USB disconnect/reconnect. But I notice that I have to close the serial terminal before re-plugging. Otherwise COM36 is grayed out (disabled) in the IDE and nothing is possible.
I will now proceed with my actual programming tasks
It is easy to make the assumption that a bug that affects you also affects all users universally. This is not always the case. Problems with the IDE may be specific to the environment it runs on in your PC, even network, and there are so many factors that the specific relevant factors in your particular environment might be very rare or even unique.
Your finding that the problem is intermittent indicates that even your environment only provides the necessary conditions occasionally.
I note you are using Windows 7. That is very unusual these days and is not a supported operating system for Arduino IDE 2.x. I know that some have reported it working, and I'm not saying it is definitely the cause of the problem you experienced, but it is noteworthy.
I just did an upload to my MKR NB 1500 with Arduino IDE 2.0.1 and the correct port was selected after the upload. I do a lot of uploads and have not experienced this problem.
The native USB boards that do this port number switching during the upload are very common these days, so there are definitely thousands of users doing these uploads, yet we do not have a report of this problem in the issue tracker.
I haven't found any.
I remember having this type of problem a lot with the Nano 33 BLE specifically and Arduino IDE 1.x (2.x did not exist at that time) some years back, and also seeing reports from others about it. However, I haven't experienced that problem for quite some time and haven't seen any reports of it, even for Arduino IDE 1.x, so I'm not sure what changed.
You reported a problem associated with the way the IDE handles the port cycle resulting from activating the bootloader manually:
That is likely to occur during normal usage of the Leonardo and Micro boards, which trigger the bootloader on a single reset. The bug can occur for the MKR NB 1500 also, but only when the user does a double reset. It will never occur from a single reset because the bootloader doesn't run after a single reset. Since @bomber67 did not mention the problem being associated with doing a double reset (which is the sort of thing you remember doing), I am doubtful it is directly related.
It will be difficult to investigate the problem if we don't know for certain what the board was doing.
For example, it might be something like this:
COM37
COM36
COM37
(normal sequence)
COM37
COM36
COM38
(operating system enumerated application port to a new address)
Or this:
COM36
COM37
(board was already in bootloader mode before starting the upload)
Or this:
COM37
COM36
No port
(the uploaded sketch disabled or broke the code that generates the board's USB CDC serial port)
