Fresh install problems?

I’ve seen a number of problems recently of people who just installed Arduino for the first time not recognizing the Arduboy.

Does anyone who already has a functioning Arduboy and development environment have another computer that doesn’t have Arduino on it?

If someone who is familiar with how Arduboy is supposed to run and flash, can try a sanity check for me and install Arduino on a fresh system to check if there are any issues?

I’m going to uninstall Arduino and reinstall it to test it myself, but would be good to have some more examples.

So, on my system after uninstalling Arudino, the Arduboy still shows up in ports as “USB Serial Device”:

Within Control Panel -> Devices and Printers it shows up like this:

After installing Arduino, the Devices and Printers looks the same but Device Manager will be different:

When you remove Arduino IDE it doesn’t remove the installed driver.
with Arduboy connected and identified as a COM port. In device manager, right click it and uninstall the driver and place a checkmark to remove the driver. this will give more genuine ‘clean install issues’

I think you are mistaken, the Arduboy will always show up as “USB Serial Device” regardless of whether you have a driver installed, this is the default windows serial driver.

What I didn’t know is that within “Devices & Printers” it apparently polls the device information so it label it “Arduino Leonardo”

It will only show up in device manager as “Arduino Leonardo” if the driver is installed. Whether the driver is installed or not does not seem to effect how it is displayed in “Devices & Printers”.

And after trying the process again, uninstalling Arduino does in fact seem to uninstall the driver.

Ah yes when you have (a recent update of) Windows 10. Windows 8.1 and older doesn’t have a default Windows driver that works with Arduino/Arduboy.

Good to know!

Based on this it seems that if you get the butterfly error it’s because the system isn’t actually talking to the bootloader.

I read this:

In Arduino core CDC.cpp we can see that CDC not only waiting baudrate 1200, but CDC checking DTR value. If DTR goes high, CDC cancels to jump into the bootloader.

And I’m kind of wondering if this is around where the issue lies. Again, I’m kind of wondering if Arduino changed the way they are causing the reboot with the serial port.

Or maybe just perhaps some peoples systems have some other inherent USB boggle that causes an issue?

I did a compare between Arduino 1.8.5 and 1.8.9 on CDC.cpp there are changes but not in the DTR testing. However there is a change in when the reset test/request is made:

In Arduino 1.8.5 a reset test/request is handled on these USB requests:
CDC_SET_LINE_CODING
CDC_SET_CONTROL_LINE_STATE

In Arduino 1.8.9 the reset test/request is handled only on USB request:
CDC_SET_CONTROL_LINE_STATE

The CDC_SET_LINE_CODING request basically set the baudrate and DTR state (and some other parameters) all in one go

The CDC_SET_CONTROL_LINE_STATE only sets the DTR state

So if the virtual com port driver on the host side only sends a CDC_SET_LINE_CODING when opening a com port and doesn’t follow up with a CDC_SET_CONTROL_LINE_STATE to set the DTR state a reset will not occure when the sketch was compiled with Arduino 1.8.9

I’m not sure what packages the virtual com port driver sends when a port is opened without monitoring USB traffic. I doubt though that this is causing the recent issues. As I traced back the CDC.cpp changes to Arduino 1.8.6 whichwas released in August last year.

But to rule out this possibility one could install Arduino 1.8.5 and try uploading through the IDE then.

1 Like

Ah nuts, yeah august last year is too far back for this change. Although I do kind of suspect this is related to the problems. But hopefully/unfortunately is client side related issues.