Arduinos & COM ports?

I am working on a serial link between a Mega and a Uno and everything was working yesterday before I shut down for the night. The Mega was on COM13 and the Uno on COM17. IDE is on a Windows 7 PC

When I fired up this morning, and plugged in the boards, the Uno wouldn't upload code. The Mega works fine.

I get the following error message for the Uno:

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM17
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x1a
.
.
.
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x1a

avrdude done.  Thank you.

Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

When I swapped the Uno and the Mega, the Mega still shows up as connected to COM13 though it is on a different USB port and the Uno still comes up as COM17. The Mega will still upload properly and the Uno still says "not in sync".

It looks like the Arduinos take their COM assignment with them, which doesn't make sense!

I can't change the COM and the Uno still wont upload - no activity on the Tx & Rx leds (except for an initial blink.

If I blew my USB port on the Uno, how would windows know which device was connected to which port?

An error occurred while uploading the sketchC:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf 
-v -patmega328p -carduino -PCOM17 -b115200 -D -Uflash:w:C:\Users\Dianne\AppData\Local\Temp\arduino_build_504520/SerialReceiveWithStruct.ino.hex:i 

avrdude: Version 6.3, compiled on Sep 12 2016 at 17:24:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM17
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0xa5

I don't understand what is happening!!!

(deleted)

I DID. When I disconnected everything, the code loaded!

What's that about?

(deleted)

spycatcher2k:
Could be that pins 0 or 1 had something attached (NOT a good idea) or the items were loading the Arduino down too much.

Nothing was attached to the Tx & R pins.

I disconnected everything and tried again - this time it uploaded!

I hooked everything back up and it wouldn't upload so I put the Uno on an external power supply and now it is working.

Doesn't seem like there would be much current drain with the items I had attached to it but I guess it didn't like the "load" on its ports. STRANGE that it worked yesterday and with NO hardware changes it wouldn't work today......

"Working" was only temporary!

When I re-started the Uno again, it doesn't show COM17 - it shows up on COM13, same as the Mega board and I can't change it to COM17.

When I open Windows devise manager, it is showing up as a "ATmega 16U2 DFU" WTF!!??

Tried different ports, tried a whole bunch of stuff but nothing seems to be reliable from one attempt to the next.

Going to leave it aside for the time being before I loose my temper and start smashing things!

Going to leave it aside for the time being before I loose my temper and start smashing things!

You don't have to break Windows, it comes already broken!

In detail, the USB drivers attempt to connect a device to the same COM port it was on before it got disconnected. This works great for printers but not so good when you have a bunch of similar devices. Every USB device has properties named VID (Vendor ID), PID (Product ID), and Serial. Windows game is to record in its registry the values it gets when it first sees the device and uses an INF file or some other means to associate the device with its device driver software. The name from the inf file gets stored in the registry.

The best way for you to play the game is to unplug your Arduino devices and restart Windows (this kills off some of the caching of device information). After Windows is restarted plug your device into the same USB 2 port you had been using and give Windows a few seconds to recognize it. (Windows plays some different game with USB3 and this is not recommended).

Do be aware that some Arduino models also play games with USB. The magic Arduino bootloader resets the Arduino and it may hop to a different USB port. When you hear Windows tweedle when you connect or disconnect an Arduino is a move in the Windows side of the game and the reconnect may end up on a different port number. I don't know the rules of all these games but sometimes the virtual com port numbers seem to always increase.

So don't lose your temper, just be a good sport and learn to play the game.

Thanks Dude - I will try to 'play the game' (but I have never been good at games).

SurfingDude:
You don't have to break Windows, it comes already broken!

I see you and I share the same opinion of Microsoft products! :wink:

If I connect the Arduinos before I power-up the computer, everything seems to come up okay. Seems that way Windows finds everything and maps it to the right place.

Now back to working on software.....

After extensive trail-and-error testing I have determined that the source of the problem is the serial line from Tx pin 18 on the Mega to Rx pin 12 on the Uno.

When this line is connected it seems to 'leak power' from the Mega to the Uno board and prevent the Uno from powering-up properly. When that happens, I have trouble getting it to connect to the right COM port on the PC and, when it does connect, I can not upload software.

When I disconnect the serial line until after powering-up both modules and uploading the code the first time, everything works fine. Subsequent uploads work, the code works, and everything is fine as long as I don't power-down anything. It wont matter in the final configuration because the serial will be on a radio link but it is a P.I.T.A. on the development bench.

Has anyone else run into this? Do you use a capacitor for "DC decoupling"?

(deleted)