need help diagnosing burnt arduino nano v3

Development Tools IDE 1.x
1

Hello,
Im new here & new to arduino.
I'm having a serious problem with my nano that I'm trying to work through.
Basically, I accidentally shorted the nano, and can't seem to revive it.

here's what happened & my troubleshooting steps so far:

  1. When making a ground connection to the ground pad next to D2, I believe that I accidentally shorted to the solder pad for the Tx LED.
  2. upon researching the problem, it seemed that I had blown the schottky diode on the backside (near the regulator).
  • USB power didn't work at all, but connecting an avr programmer to the ISP headers seemed to work in reviving the board
  • with the external 5V source from the programmer, the board would fire up, yet I didn't actually try programming it at this point...
  • upon starting up the board, the Tx & Rx LEDS flashed quickly a few times, and then stayed off
  • after that, the power LED lit up and the indicator LED started to blink at approx. 1 second intervals, so I was under the impression that everything was working fine
    -- prior to that, I believe that I had tried to load the blink example during my initial troubleshooting, so now I'm not sure if that blinking was from the blink code, or if it was some sort of 'error indicator' from the ATMega328 (more on this below...)
  1. Since I believed that it was an easy fix to just replace the diode, I went ahead & ordered some new diodes from ebay.
  • However, based on a user recommendation from another forum post, I created a temporary jumper across the diode gap so that I could get usb connectivity.
  • By using the jumper, the board successfully powered up via USB, but I couldn't program it either via USB or with the external ISP programmer
    -- trying to program via USB gave me the stk500_getync error, while avrdude w/ the external programmer gave me the 'device init. failed' message
  1. next, I tried the loopback test...
  • I jumper'ed the tx => rx pins, and also the gnd => rst pins...
  • I opened up the terminal, and confirmed through 'serial monitor' that my input was successfully being echoed back to me...
  • so, at that point, I figured that the FTDI chip was still functionally intact
  1. Here's where the serious problems begin...
  • Upon removing both the tx=>rx and gnd=>rst jumpers and trying to start the board up, The Tx and Rx LED's lit up brightly and stayed lit constantly, but nothing else happened
  • during removal of the jumpers, i didn't alter or change anything else...it was very straightforward, so there was no chance of having damaged something
  • There was no other kind of flashing or changes to indicate that the nano was responding
  • checked the 5V pad, and there was 5V there
  • checked the 3.3V pad, and there was only ~1.5V
  • tried doing the loopback test again, yet got the same results...TX & RX LED's light up & stay lit, FTDI chip no longer responds and is not recognized by windows as being connected as a com port

So, now, I'm stuck and don't know what else to check...
I know I can just order another nano, but I'm on a stubborn mission to try to save this one, even if I have to replace the FTDI chip and/or the ATMega.
Though I'm not an electronics expert, I do have access to a rework station & I'm comfortable replacing the SMD components, so I have no problem switching out whichever components need to be replaced. So, I'm willing to try fixing it, as long as the total price for the components doesn't end up being more than the cost of the nano itself...

Anyway, can someone please help me figure out what the next steps should be in order to troubleshoot this?

2

FTDI chip creates 50mA of 3.3V. If you're only seeing 1.5V, the 3.3V line is either shorted somewhere, or the FTDI chip is shot & unable to power itself internally for the USB interface.
Good luck replacing it - I am not able to solder stuff that small myself.

3

CrossRoads:
FTDI chip creates 50mA of 3.3V. If you're only seeing 1.5V, the 3.3V line is either shorted somewhere, or the FTDI chip is shot & unable to power itself internally for the USB interface.
Good luck replacing it - I am not able to solder stuff that small myself.

ok, thanks for the feedback...
Can you recommend a method to 100% confirm that the FTDI chip is dead?

I've had some luck with drag-soldering in the past.
Assuming I can flow & remove the chip without any damage, I'm hoping that it wouldn't be too bad to get a new one installed.

4

No 3.3V, No USB connection - what else is there?

5

CrossRoads:
No 3.3V, No USB connection - what else is there?

so would the FTDI going bad cause the Tx & Rx LEDS to stay lit and cause the board to not work even when not using the USB connection (using the external ISP programmer) ???
I'm confused about this...

6

csurf:

CrossRoads:
No 3.3V, No USB connection - what else is there?

so would the FTDI going bad cause the Tx & Rx LEDS to stay lit and cause the board to not work even when not using the USB connection (using the external ISP programmer) ???
I'm confused about this...

The RX and TX LEDs are driven by the FTDI chip, but as active low signals. I suppose grounding the power to gnd pins on the FTDI and then applying signal voltages to it's input pins could cause damage. The currently damaged FTDI chip may be causing other odd behavior through it's interconnects to the Atmega.

It might be an interesting exercise to remove the FTDI chip and then try to program the Atmega with ICSP. (Of course, make sure none of the lands in the FTDI's footprint are shorted with leftover solder from the removal process...) :wink:

7

Sembazuru:

csurf:

CrossRoads:
No 3.3V, No USB connection - what else is there?

so would the FTDI going bad cause the Tx & Rx LEDS to stay lit and cause the board to not work even when not using the USB connection (using the external ISP programmer) ???
I'm confused about this...

The RX and TX LEDs are driven by the FTDI chip, but as active low signals. I suppose grounding the power to gnd pins on the FTDI and then applying signal voltages to it's input pins could cause damage. The currently damaged FTDI chip may be causing other odd behavior through it's interconnects to the Atmega.

It might be an interesting exercise to remove the FTDI chip and then try to program the Atmega with ICSP. (Of course, make sure none of the lands in the FTDI's footprint are shorted with leftover solder from the removal process...) :wink:

After messing with it a lot, i finally got the board back online...
It turns out that I had damaged a couple of the pads when I had initially freaked out & removed all of the header pins from the board (yes, i know, it was a stupid move, but I was desperate & a little drunk, so I started manhandling the board in order to remove all of the pins).

It turned out that the MISO connection on the D12 pad was damaged, and it wasn't making it through from the ICSP header to the MCU.
The 5V pad was also damaged, and I had idiotically jumper'ed it to the wrong location.

Once I fixed those two problems, the FTDI chip came back to life.
I was also able to get communication up between the MCU and avrdude using my external programmer.
At first, it struggled to successfully upload sketches, and would error out every couple of attempts .
The other weird thing is that programming via USB still didn't work; I would still get the 'getsync' error.
So, out of desperation, I tried re-burning the bootloader with the external programmer.
After that finished successfully, USB programming started working again, and the uploads via the external programmer no longer had any issues...

So, now, I have a 'crippled' yet functional board (the 5V and D12 pins are no longer useful as they've got jumper wires in their place).
Still, I'm stoked that its not a total loss...If I need 5V, I guess that I'll just have to tap into the ICSP 5V pin or figure something else out.

Thanks for the help you guys! :slight_smile: