Syborg64:
I've used this board on a number of different machines but never has it showed up as two different ports.
That doesn't mean it didn't happen, only that you haven't noticed it.
Using the information HERE, I showed all of the comm ports on my computer, a portion of which is shown in the attachment. In there, you can see several sets of Yun serial ports:
- COM6 (normal port) and COM7 (bootloader port)
- COM11 (normal port) and COM12 (bootloader port)
- COM15 (normal port) and COM16 (bootloader port)
- COM32 (normal port) and COM33 (bootloader port)
- COM39 (normal port) and no associated bootloader port
I suspect that if I were to plug a Yun into the USB ports where it enumerates as COM6, COM11, COM15, or COM32, I would have no issues loading code. But if I were to load code when it is enumerated as COM39, I could have problems. (I don't have time to try plugging a Yun into my multitude of USB sockets and see if it will load code in each one.) I do recall having trouble getting the bootloader to be recognized in the past, but I don't know if it was the Yun enumerated as COM39 - because I do a lot of embedded development (it's not only a hobby, but has been my profession for over 30 years) I occasionally delete the multitude of serial ports or I would have hundreds of comm ports hanging around. So it's equally possible that I plugged a Yun into a port that resulted in COM39, and haven't tried loading code yet from that port.
I used a USB hub to add extra physical USB ports as the board had been plugged in each one (just in case) and when I pugged it in I got a windows notification in the lower left corner of the screen saying it was configuring arduino yun. (good sign?) then is said it was ready, so I sent an upload and the same exact thing happened.
If by the same thing, you mean you heard the disconnected sound, then that means the "normal" port is being closed. But if the "bootloader" port is not being recognized, that seems to be pointing to a problem with the driver setup on your Windows computer which prevents it from recognizing the bootloader port, or perhaps all of those ports have already tried and failed to enumerate the bootloader in the past? I'm not a Windows or driver expert, so I can't really say for sure.
So I tried in on an other port of the hub and again it said configuring. I clicked on it, took me to win10 settings app. It seems to recognize the yun as a keyboard judging by the icon next to it.
Interesting. What sketch is currently loaded on the Yun? Is it a sketch which makes it act like a keyboard or generic HID device? The way I understand it, the bootloader is triggered by the way that the normal serial port is closed/reopened when starting to load code. If the Yun is acting as a HID device, maybe it doesn't react the same way and doesn't enter the bootloader? Perhaps loading a standard sketch (Blink?) will make it work properly? Oh, wait, you're having trouble loading a sketch... (more on that idea in a moment.)
If it's a problem with the bootloader, would "burn bootloader" help? I have no idea what it really does and I don't own the board, it's my school's.
It might. Burning the bootloader means to program a fresh copy of the bootloader onto the board. You need external hardware to do this, either using a programming pod, or using another Arduino as the pod.
But there is another option with the Yun: try loading a sketch over the network (wireless WiFi or wired Ethernet, it makes no difference.) On the Arduino IDE "Port" menu, select the Yun's network address instead of a COM port. Then, when you load a sketch (I would suggest the standard Blink example) it will load a fresh copy of the bootloader when it programs the sketch. It's a useful side effect of programming over the network that it reloads the bootloader.
I have managed to upload from this computer and very probably to this very card
I don't doubt that. Maybe something has changed in the driver files (maybe reload the Arduino IDE?) or maybe it's something in the currently loaded sketch (is it acting as a keyboard?) or maybe the bootloader got clobbered somehow (You mention using an AVRISP mkII, and if that's how code was previously loaded on the board, that could clobber the bootloader.)
