IDE 2.2.1 not uploading, device not found, exit status 1

Development Tools IDE 2.x
1

Hi all, I'm having an ongoing connection and reliability issue with the IDE and how it connects to the device. This is not a new issue, I first ran into it in 2022 with two other Nano 33 IoT's.

I've written 1500 lines of code that runs on those continuously every day. During development I had connection reliability with a beta 2.0 version of the IDE, and am having it even worse now.

I have a Nano 33 IoT, my 3rd one. Sometimes, rarely, I can upload the blink sketch to it, but cannot find a sequence of steps that ALWAYS works. Most of the tries the ide does not find the com port. I verify that I'm getting an upload by seeing the fading light, and by changing the on/off timing each time, for certainty.

Even the double press of the device button doesn't always work!

I have verified the com3 port with Device Manager. Sometimes even when connected, during the upload when it succeeds, it will change the port to com4.

This is the only device connected to my Win 10 machine (AMD 5950x), so there is no issue with selecting the com port.

As these issues span 3 different Nanos, and this is a brand new, first time install on this machine, and the com port is verified in Device Manager, and the IDE shows board and port selection are correct, and shows valid Board Info when device is read, and the IDE says it is connected to the correct (only) device on the correct port, every issue I can think of and have looked up on the forum are correct. No pins of the Nano are connected.

I am at a loss to understand what is going on here. Professional programmer, been programming C since 1984, electronics since 2003.

We really need more info out of the IDE beyond "status 1". What does this mean, in detail where we might figure out what the issue is?

My copy of the blink code simply changes the time delays so I can be sure I'm looking at a new upload running.

The degree of erratic instability make the IDE (I believe it's not the Arduino Nano) very difficult for users and will REALLY turn off new adopters. Is there another development platform that will be much more reliable?

Closing/reopening the IDE may work once, but it won't then repeat an upload. Similarly rebooting the machine hasn't worked.

For example, rebooting the machine, bringing up IDE, and Device Manager which shows device is on com3 (only one in existence), Board Info shows correct data, and selecting the board + com3 port (only one available), uploading does trigger the fading of the Nano, but it still fails.

Even though it was successfully connected to com3, see the message says it tried com4. Yet the IDE status line still shows it thinks device is on com3 (not connected). The drop down shows it thinks it is on com4. IDE sections have gotten confused.

After failure, reselecting board on NEWLY assigned port, upload then succeeds. And puts connection back to com3. Trying same cycle again, IDE fails to trigger upload fade of Nano, port remains at com3 in status and in drop down, and Board Info still works.

Trying upload again, fails again. Restarting IDE, verifying Device Manager on com3, checking status line is com3, drop down is com3, selecting board + port in drop down, upload again fails.

This is what I mean by erratic. Sometimes it works, most times it fails.

Finding trick of ALWAYS selecting board + port, as status line is often out of sync.
Double pressing Nano button, selecting board + port, uploading--that worked.

Next try without the double press--failed.

Next try WITH the double press--it failed too.

Arrghhhh!

But I notice that last failure has changed the com port to com4. Trying upload now SUCCEEDS! And resets back to com3.

Double pressing appears to reset to com4 every other time.

Only when: **
** 1) uploading to com4 (not selectable--Nano has to trigger this), will an upload SUCCEED.

For successful uploads, **
** 1) Double pressing appears to reset to com4 every time (?). Watch this.
** 2) SELECT board+port in drop down as com4, **
** 3) THEN uploading, **

-- that WORKS!

Have done a few cycles of this, and it appears this may work consistently.

Without BOTH those steps, if you skip EITHER one, uploading will Fail.

SEE WHAT I MEAN BY THIS BEING TOO HARD FOR NEWBIES AND GENERAL ADOPTION? THE COST OF FIGURING THIS OUT ON OUR OWN IS TOO HIGH! IT IS NOWHERE TO BE FOUND IN YOUR DOCS OR FORUM; only pieces, amid MUCH misdirection about "powered correctly", board selection and port selection (NOTHING about how the IDE changes this every time, and that you MUST reselect manually else IDE will remain confused (status line vs drop down) and refuse to upload even though Board Info reports correctly.

This has cost an experienced programmer 7 hours, even though I did it before 18 months ago (ahhh, memory, the light on the Nano isn't the only thing that fades.)

I'll bet if you get the other sections, which the status line reports, to be synced with the drop down on all changes, the error goes away.

THIS SHOULD WORK, OUT OF THE BOX, EVERY TIME! Watch your sales and adoption Increase!

Here is the error message:

"C:\Users\Dan\AppData\Local\Arduino15\packages\arduino\tools\arm-none-eabi-gcc\7-2017q4/bin/arm-none-eabi-size" -A "C:\Users\Dan\AppData\Local\Temp\arduino\sketches\8E1DB89F8C0390D640814AC482DFC11B/BlinkMine.ino.elf"
Sketch uses 14020 bytes (5%) of program storage space. Maximum is 262144 bytes.
Global variables use 3564 bytes (10%) of dynamic memory, leaving 29204 bytes for local variables. Maximum is 32768 bytes.
Performing 1200-bps touch reset on serial port COM3
Waiting for upload port...
Upload port found on COM4
No device found on COM4
"C:\Users\Dan\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.7.0-arduino3/bossac.exe" -i -d --port=COM4 -U true -i -e -w -v "C:\Users\Dan\AppData\Local\Temp\arduino\sketches\8E1DB89F8C0390D640814AC482DFC11B/BlinkMine.ino.bin" -R
Failed uploading: uploading error: exit status 1

Other tries' error message:
Sketch uses 14020 bytes (5%) of program storage space. Maximum is 262144 bytes.
Global variables use 3564 bytes (10%) of dynamic memory, leaving 29204 bytes for local variables. Maximum is 32768 bytes.
Waiting for upload port...
No upload port found, using COM3 as fallback
No device found on COM3
"C:\Users\Dan\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.7.0-arduino3/bossac.exe" -i -d --port=COM3 -U true -i -e -w -v "C:\Users\Dan\AppData\Local\Temp\arduino\sketches\8E1DB89F8C0390D640814AC482DFC11B/BlinkMine.ino.bin" -R
Failed uploading: uploading error: exit status 1

2

Hi @dan39johnson

This behavior is normal and expected. The way a normal upload to this type of "native USB" (where the primary microcontroller communicates directly with the computer over the USB connection) board works is:

  1. User triggers an "Upload" operation.
  2. Arduino IDE sends a special signal over the selected serial port for the microcontroller on the target board to activate the bootloader program.
  3. The microcontroller on the target board exits from the sketch program.
    This causes the USB CDC serial port on your computer that was produced by the sketch program to disappear.
  4. The microcontroller on the target board starts the bootloader program.
  5. The bootloader program produces a new USB CDC serial port on your computer.
  6. Windows enumerates the serial port. Since the board is identified as a different device when the bootloader program is running on it, Windows assigns it a different port number than it assigns when the board is running the sketch program.
  7. Arduino IDE sees the appearance of a new port and sends the compiled sketch program to that port.
  8. The bootloader program receives the compiled sketch program from the computer and writes it to the flash memory on the microcontroller.
  9. The bootloader program exits.
    This causes the USB CDC serial port on your computer that was produced by the bootloader program to disappear.
  10. The microcontroller on the target board starts the sketch program.
  11. The sketch program produces a USB CDC serial port on your computer.
  12. Windows enumerates the serial port.
    Windows will assign the board the same port number as it had before the "Upload" operation was triggered.

This is the intended behavior. Arduino IDE knows that the upload will trigger a port switch so it doesn't attempt to update the user's port selection until after the upload is finished. The only thing that matters is that it detects the port produced by the bootloader program and sends the sketch program to that port. You yourself have pointed out that it does this so all is well as far as the port detection is concerned.

Nope. The board selector menu on the Arduino IDE toolbar is a list of all the ports Arduino IDE detected on your computer. So the only correct behavior for this menu is that it should reflect the disappearance of the sketch program's port (in your case COM3) and the appearance of the bootloader program's port (in your case COM4). If you look closely at the menu, you'll see that COM4 does not have the highlight that indicates it is the selected port. So there is no contradiction between what is shown in this menu and what is shown on the status bar.

This is because the double reset causes the bootloader program to run, as occurs at step (6) of the procedure I described above during a normal upload.

I see that you are right. I was quite disappointed to discover that this important information is not documented. That is a serious deficiency in the documentation.

The helpers here on the forum are quite familiar with this technique and frequently suggest it to people having problems uploading to their Nano 33 IoT and similar boards:

https://forum.arduino.cc/search?expanded=true&q=nano%2033%20iot%20double%20reset

Out of the box, certainly. In my experience it does and certainly many thousands of other happy users had the same experience. Unfortunately there will also be the small number of users with some unusual system configuration that won't have such a good experience. If you are one of the latter group, it is easy to get the impression that 100% of users have the same experience. But regardless even if you realize that you are in the unlucky 0.1% it still doesn't make the experience any more pleasant.

However, it simply isn't possible to avoid the need to occasionally perform the double reset + select port procedure when using native USB boards. The reason is that the USB stack that produces the USB CDC serial port and recognizes the "1200 bps touch" signal sent by the IDE during the "Upload" operation is running on the same microcontroller as the sketch. This means the sketch code can cause the normal upload to no longer work. That might be the expected result of the code (e.g., if it puts the microcontroller to sleep), or the unexpected result of a bug (e.g., a divide by zero crashing the processor). There simply isn't a magic wand that Arduino can wave to avoid this fact. We can try to make embedded systems as accessible as possible, but they will still be technically complex in the end and the users must be willing to persevere through inevitable challenges to accomplish their goals.

The users will have a more gentle learning curve if they use one of the boards that has a dedicated USB chip (e.g., Uno, Mega, classic Nano). You might consider purchasing that type of board. If you need the Wi-Fi connectivity capability, you can look at the ESP8266 or classic ESP32 (but not the ESP32-C3 and ESP32-S3 as these are also native USB) boards, which also have a dedicated USB chip.

Arduino does have the responsibility for clearly documenting the procedure for recovering the board from the state where a normal upload is not possible.

Was the board in the bootloader mode (where the LED is pulsing) when you did this? If so, the cause of this specific failure was probably that you didn't select the port of the board before triggering the "Upload" operation. When you don't have the correct port selected, Arduino IDE attempts to send the sketch program to the wrong port, which causes the upload process to fail.

In this one, I can see that you did have the correct port selected. It is not clear to me why this upload failed. This is unusual. It is maybe possible that the sketch running on the board caused the upload failure (though usually that has different symptoms). Does the problem still occur during uploads when the board is running the bare minimum sketch you get from selecting File > New Sketch from the Arduino IDE menus? Note that I wrote "running", by which I mean you should have successfully uploaded that sketch previously, as the significant factor in this case is which sketch is already running on the board before the upload starts, rather than which sketch is being uploaded to the board.

3

I've got the same issue. Win 10, Arduino Nano 33 IoT. There are a lot of random issues. (Figured out the double clicking button through a lot of forum posts.) Rebooting sometimes helps but not for long. Similar experience to the first poster. It's random. Often resetting the nano, ensuring the port is set properly then letting it sit for five minutes is the only thing that works. And even that is intermittent. Been beating my head against it for several days now. Saw some other posts about this too from back in July. (STILL OPEN: Uploading fails, COM Port issue) Any idea how to fix it?

Edit: And now it no longer detects the Arduino. Again.

4

This is all happening when trying to run the Blink sketch. There should not be a single sketch which runs and causes an upload failure. If it did, that would be the LAST sketch that device could run!

5

Yesterday I found after many uploads of different example sketches, that the IDE would not respond to the device at all. Double press of the Nano's button didn't cause the IDE to recognize it.

Closing & reopening the IDE didn't cure. I reinstalled the IDE, which also didn't help. How could THAT be??

Rebooting the whole computer did cure it.

We're not supposed to have to press the physical button to do an upload, correct? What would happen if doing an over the air upload?

6

No, that is not correct! The IDE stays stuck on port 3 while the device is connected on port 4, after pressing the button twice. The IDE WILL NOT upload at that point.

One can see this in the disparity between the drop down and the status line.

Uploading will fail every time here.

The ONLY, and necessary, remedy is that I must again choose the drop down and reselect the board with the new port com4, while the status line is saying com3.

This CANNOT be the intended behavior, as uploading is supposed to happen whenever we click on that IDE button, correct? Current behavior is definite, consistent, and it means the uploading process is dead in the water, cannot be done no matter how you hold your mouth, without that additional operation.

The IDE does capture the fact that an upload has been called for from the device and reflects this in the new connection on com4. At that point, the rest of the IDE, certainly the uploading logic, is out of sync with that state change.

We're suppose to be able to upload by clicking on the IDE button, without physically touching the device, correct?

Mind you, ALL these issues are happening running the Blink sketch on a fresh install of the 2.2.1 IDE, on an Arduino Nano 33 IoT, not on some other third party board, so there is no other vendor involved here. I'm running Win 10 up to date, on an AMD 5950X, Gigabyte motherboard, 32 GB.

Isn't this a very standard platform? And vanilla situation?

7

Blockquote Out of the box, certainly. In my experience it does and certainly many thousands of other happy users had the same experience. Unfortunately there will also be the small number of users with some unusual system configuration that won't have such a good experience. If you are one of the latter group, it is easy to get the impression that 100% of users have the same experience. But regardless even if you realize that you are in the unlucky 0.1% it still doesn't make the experience any more pleasant.

However, it simply isn't possible to avoid the need to occasionally perform the double reset + select port procedure when using native USB boards. The reason is that the USB stack that produces the USB CDC serial port and recognizes the "1200 bps touch" signal sent by the IDE during the "Upload" operation is running on the same microcontroller as the sketch. This means the sketch code can cause the normal upload to no longer work. That might be the expected result of the code (e.g., if it puts the microcontroller to sleep), or the unexpected result of a bug (e.g., a divide by zero crashing the processor). There simply isn't a magic wand that Arduino can wave to avoid this fact. We can try to make embedded systems as accessible as possible, but they will still be technically complex in the end and the users must be willing to persevere through inevitable challenges to accomplish their goals.

The users will have a more gentle learning curve if they use one of the boards that has a dedicated USB chip (e.g., Uno, Mega, classic Nano). You might consider purchasing that type of board. If you need the Wi-Fi connectivity capability, you can look at the ESP8266 or classic ESP32 (but not the ESP32-C3 and ESP32-S3 as these are also native USB) boards, which also have a dedicated USB chip.

Arduino does have the responsibility for clearly documenting the procedure for recovering the

Blockquote

That's the core issue: this Is an Arduino Nano 33 IoT, not a knockoff, running the Blink example, and it's a brand new first-time install of the IDE, on a current state of the art win 10 machine.

This isn't a 0.1% situation. It should be a 100% out of the box situation, is it not?

8

A post was split to a new topic: Upload to Nano 33 IoT fails: "device not found, exit status 1"

9

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.