Hey folks now here's the thing . I've taken up the challenge to fix bricked arduinos and now let me discuss the issue i have .
Arduino 1 :
The "L" LED used to be always on , the code never uploaded to the board it was something like as if it is in a fixed position like that . Whenever I plugged in the power cable there was no blinking no response whatsoever even I tried pressing the reset switch a couple of times but nothing happened .
Solution i have tried :
I was able to get the arduino's atmega16u2 into DFU and upgrade it with latest hex file which was successful after a couple of tries
I was able to reburn the atmega328 with a new bootloader
Now the problem is even after upgrading the bootloader and the usb serial code the code does not upload .
Please provide a detailed explanation of what you mean by "does not upload", including the full and exact text of any error or warning messages you might be getting.
This is the response i am getting. And trust me if you say that this is the same skt500() issue which you commonly get i suspect that its not as it was previously in a bricked state . I have just managed to reflash the booloader into atmega328p(which as successful) and also reflash the usb to serial code into atmega16u2 using Atmel flip (which was also successful )
avrdude: Version 6.3-20190619
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "D:\Arduino\hardware\tools\avr/etc/avrdude.conf"
Using Port : COM15
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=0xe0
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0xe0
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0xe0
As I also repair Arduino boards, the first thing I do if it fails after burning the bootloader and 16u2 firmware is replace the 328. Replacing the 16u2 would be next.
This assumes you have checked both crystals, and all voltages over the board.
A strange issue I have see is removing the op-amp connected to SCK/Onboard LED has fixed a few boards over the years.
Well are you suggesting that i should just try removing the op-amp as i do have one other board on which neither the atmega16u2 went into dfu neither it responded and has a sck LED stuck also doesnt respond to any reset commands.
But for the board which has the new 16u2 firmware and the new atmega328 bootloader can u suggest me something else apart from replaceing the 16u2 . Because i already did tried replacing the atmega328 it doesnt help as i feel the problem is with atmega16u2 .
But as its getting into dfu accepting my commands i would like to try all the software fixes first .
Or what you can try is you can send me the hex file for the 16u2 i'll try flashing that maybe that helps
When i got my Uno, for a long time i was unable to upload anything normally through the USB port.
Uploading through the ICSP header worked fine. Normal serial communication worked fine. It was just the uploads that failed, even after re-burning the bootloaders for both chips many times.
I tested the traces between the two chips, measured whichever components i could without desoldering - it all looked fine...
Then one day, while messing about with the IDE, i tried using my netbook instead, and surprisingly it worked after a couple tries. It was still often failing though, so i refreshed both bootloaders with the netbook, and it started working reliably.
Moving back to my desktop PC, it was still failing most of the times. I normally had the USB cable plugged to my monitor, as nearly all USB ports on the PC are occupied already.
I freed one of the mobo ports and tried there... and it worked!
Turns out using the USB hub in my monitor was screwing things. Now, when i try again, i get protocol errors.
But using the mobo port works just fine. Its only issue is that the power is somewhat low and causing brownouts on my ESP - it often falls down to about 4.5V (vs. stable 5.10V on the monitor USB). Gotta check the power supply... someday...
So, when repairing, try to use ports directly coming from the motherboard, and avoid USB hubs.
Also, try on another PC, if possible.
Trust me i have actually tried changing the cable changing the usb port , checking the components with a multimeter even reflowing most of the components around the usb-uart chip but nothing seems to work out.