Arduino UNO unable to connect via USB

[drpe]

Hi.
I have a problem.

My PC did recognize my Arduino UNO and it worked fine for a few days until it doesn't anymore. The last script I uploaded (my own version of blink, in plain C) works whenever I power my Arduino but my PC doesn't recognize it anymore, so I can´t upload another program or do anything else but see that LED blink over and over.

I was working without the IDE, using avr-gcc, and uploading my scripts with avrdude. All this working from my WSL (Ubuntu + Win10). Yesterday I connected my board via USB to upload another script and my computer doesn´t recognize it anymore. Not in the WSL nor in "pure" Windows 10. My laptop (with W10 too) doesn't recognize it either.
But the board seems to function; the POWER light is on, the script works, the RESET button makes the LED blink in that way we all know...

Thank you all in advance :).

EDIT 30/10/2021:
The only similar problem I've seen published here is, I guess, this one:

Flashed a bad .hex file, Arduino UNO doesn't work anymore

I flashed a bad .hex file using Atmel FLIP to my Arduino UNO. I can no longer flash other files to it or upload a sketch. I tried to find other solutions, but no one has the same problem as I do. I have gone through the Arduino support. It says i have a corrupted bootloader. But I can't burn it, because I don't have another Arduino. Is there any way to burn the bootloader without any other hardware?

But it's unsolved and actually they didn´t use the same setup I was using.

UPDATE 17/11/2021:
I bought another UNO, a 100% original one, and I used it to reprogram the bootloader of the one that is "broken".
It seems that the reprogramming worked, and my old UNO doesn´t executes the last script I uploaded anymore. However, it's still unrecognized via USB. I guess I'll try to reprogram the 16U2, but I need some more extra info before.

[sterretje]

What do your computers think about your board. In Windows, use device manager; any (additional) yellow triangles when you connect the board. USB cable properly inserted at both sides? Did you use the same cable?

What was all connected to the board when it worked the last time? How was your board powered? USB only or via V_in / barrel.

Which TTL-to-USB converter does your board use? It's the chip closest to the USB port; originals and faithfull clones use the 16U2, other clones often use the CH340 and sometimes FT232 or CP2102.

[drpe]

I've tried with another cable (besides the original one) and other USB ports; and no results either: my Windows device manager doesn´t change at all.

When I was working with it I was just using the built-in LED, while the board was powered via USB (front port).

My board uses 16U2... Well, the chip says that: MEGA16U2.

PS: Maybe it's useful to share my avrdude commands:

avrdude -F -V -c arduino -p atmega328p -P $(USBPORT) -b 115200 -U flash:w:$<

Where $(USBPORT) is a Makefile variable that holds /dev/ttyS3, because it was in Serial Port COM3 (for Windows, ttyS3 for Ubuntu), and $< stands for my .hex file.

I want to point that this setup was working fine. I guess that what changed is that I tried to declare some things outside the .c file (I was using just that one so far) and I created a .h file, maybe I compiled them both wrongly, but as long as I know that can´t cause this problem.

[TomGeorge]

Hi, @drpe
Look at the end solution to this thread, a similar problem I believe.

Nano not communicating with computer

I've done both of those, the IDE shows Com5 and Com6 on the "Tools/Ports" but no board associated with them, either plugged in or not. Device manager shows Com5 as being active but not as a Nano. It has substituted a Windows driver for Bluetooth. I can't read the marking on the chip but it look like it might be a CH340. I'm seriously leaning towards as bad data cable, but can't be sure until I get some parts next week, so the project is on hold for the moment

Microsoft update caused so problems with USB driver.

Tom...

[Ballscrewbob]

A CH340 based board will not usually show up as a specific board such as UNO or NANO etc.
It simply shows up as a COM port.
That is the very nature of the CH340.

The only way to discern which is the board you want is to usually unplug the board you want to work on. This whilst watching in DEVICE MANAGER to see which COM port goes away.
Then that is the COM port you want to use.

[drpe]

@TomGeorge

Hi, @drpe
Look at the end solution to this thread, a similar problem I believe.
Nano not communicating with computer - #26 by chasrie

Microsoft update caused so problems with USB driver.

Tom...

The only Windows update after it stopped working is related to the "Windows Defender security intelligence". But I did have updated my Ubuntu (I'm using Ubuntu in the WSL1).
Also I installed after all this problem the Arduino soft in my Win10 laptop to try there and the problem persists.

[drpe]

@Ballscrewbob

A CH340 based board will not usually show up as a specific board such as UNO or NANO etc.
It simply shows up as a COM port.
That is the very nature of the CH340.

The only way to discern which is the board you want is to usually unplug the board you want to work on. This whilst watching in DEVICE MANAGER to see which COM port goes away.
Then that is the COM port you want to use.

Yes, and it was the COM3. But now the only Serial Port that I can see is the COM1 (reserved by default for something I don´t actually know), no matter if I plug or unplug the board.
Besides I guess it's not a CH340 based board but a 16UL one, as I read in the small chip near the USB port. And I guess it showed "Arduino UNO" and not just "COM3", but I actually don´t remember pretty well that detail.

[Ballscrewbob]

Then you may have over written the bootloader completely (not 100% sure).
That would require you to reload with another board as ICSP to restore the bootloader.

@CrossRoads @sterretje ?

[drpe]

@Ballscrewbob

Then you may have over written the bootloader completely (not 100% sure).
That would require you to reload with another board as ICSP to restore the bootloader.

@CrossRoads @sterretje ?

I was thinking of that option. Maybe I´ll have to buy another UNO.

The thing is my bootloader seems to work:

When I power up the board (aka: connect it via USB) the blink script (the last one I loaded) begins to execute. Also when I press RESET button the built-in LED blinks in the way it should (with that default pattern).

[Ballscrewbob]

If the bootloader is not present then the sketch would start (normally a little quicker)

[drpe]

Oh, I didn't know that. So maybe I did have overwritten it :(. But the RESET button seems to work too, is that possible?

Also. How could it happen? I used avrdude with this line (in a Makefile):

avrdude -F -V -c arduino -p atmega328p -P $(USBPORT) -b 115200 -U flash:w:$<

[Ballscrewbob]

Yes the reset would also work.
This is not my area of expertise which is why I called two other users in who may have more experience.

[Deltaflyer]

@drpe

ut the RESET button seems to work too, is that possible?

The reset button affects the Arduinos directly on the hardware level. If you press the, the software can do what it wants, the reset IS triggered and the controller restarts.

[sterretje]

@drpe

the RESET button makes the LED blink in that way we all know...

If it's the few quick flashes of the L led that you're referring to, that would indicate that the bootloader is OK.

@drpe

my Windows device manager doesn´t change at all.

If that is the case and it's not the cable, the 16U2 is gone. I have no idea how that would have happened from your description. It could either be electrically damaged or it lost its firmware.

Bart Ruffle's blog: DFU programming the atmega16u2 on the Arduino UNO R3 (from the other link) might work to program the firmware in the 16U2, no experience with it.

[drpe]

@sterretje

@drpe

the RESET button makes the LED blink in that way we all know...

If it's the few quick flashes of the L led that you're referring to, that would indicate that the bootloader is OK.

@Deltaflyer and @Ballscrewbob are saying the opposite or am I getting it wrong?

Anyway it seems that my only chance is to re-programm my board through another one, isn't it? If that's the case I'd like to, at least, know if it was a hardware error or if something in my way to write the board caused it, so at least I don´t repeat it. So I'll share my entire Makefile:

CC=avr-gcc
CFLAGS = -Os -DF_CPU=16000000UL -mmcu=atmega328p

USBPORT:=/dev/ttyS3

%.out: %.c
	$(CC) $(CFLAGS) $< -o $@

%.hex: %.out
	avr-objcopy -O ihex -R .eeprom $< $@

install.%: %.hex
	avrdude -c arduino -p atmega328p -P $(USBPORT) -b 115200 -U flash:w:$<

clean: 
	rm -f *.hex *.out

Is there something there? My blink_polling.c also uses a .h file I made. Without the .h file was all working ok, but maybe it's a coincidence.

[sterretje]

The bootloader is in the 328P processor and has nothing to do with the communication between the PC and the board. Think about it, the bootloader is not active when your sketch uses e.g. Serial.println() but it will still communicate with your PC (if your board is in working order).

The fact that Windows does not show any reaction in device manager indicates that the problem is after the PC and before the 328P; so that's the cable or the 16U2.

Just my thoughts.

Have you tried to revive the 16U2 with the link provided?

[drpe]

I'll give it a try in the next few days, and post here the results. Thank you :).

[TomGeorge]

Hi,
Can you please post pictures of both sides of your Nano?

Tom....

[drpe]

@TomGeorge : It´s not a Nano, but a UNO. Here it is:

[drpe]

@sterretje

The bootloader is in the 328P processor and has nothing to do with the communication between the PC and the board. Think about it, the bootloader is not active when your sketch uses e.g. Serial.println() but it will still communicate with your PC (if your board is in working order).

The fact that Windows does not show any reaction in device manager indicates that the problem is after the PC and before the 328P; so that's the cable or the 16U2.

Just my thoughts.

Have you tried to revive the 16U2 with the link provided?

I tried but my attempts to put the UNO in DFU mode, in the way the tutorial explains, failed.