Nano won't "upload" (another one, again)

Development Tools IDE 1.x
1

I am posting this reluctantly, but nothing I've tried has worked. I need some new ideas.

About a month ago I was slinging some code, passing parameters by memory (not a good idea) and I 'broke' one of my Nano's.
It's a xinda Nano V3.0 (Arduino-compatible), and I've broken this one previously by shorting 5V and GND on a breadboard and blowing the Schottky diode D1. I was able to replace the diode successfully and it's been working fine.

This time, on power-up the 'L' (d13) LED blinks quite fast (maybe 10Hz?) and the IDE (1.0.5 under openSUSE 12.3 on my Dell Inspiron 6400 laptop) says:

avrdude: stk500_recv(): programmer is not responding

If I jumper TXD to RXD, I can echo whatever I type in the terminal.

My other (identical) Nano works fine, as does my Uno, so that leaves out cables, drivers, etc. It's this particular board.

I've come to believe (can't prove it) that its the bootloader that's flashing the LED, since the last sketch successfully "uploaded" (shouldn't that really be downloaded?) doesn't touch d13.

Googling gets me unsolved cases and the troubleshooting pages here, neither of which has helped.

I have also verified the bootloader with Nick Gammon's very excellent Atmega_Board_Detector running on my Uno and wired up via ICSP. The results match my working Nano.

I'd like to fix it. I'd like to learn what I did wrong and avoid that (like I'm now powering down before fiddling with jumpers on breadboards!).

My best guess right now is that RXD (or TXD) pin on the ATmega328p is fried. If so, that won't be worth fixing...

Any other ideas or suggestions?

Thanks!
Daniel
PS: is it possible to write a sketch that "breaks" an Arduino?

2

Could you have enabled the WDT at some fast timeout? The bootloader used with a Nano doesn't handle WDT interrupts correctly and if enable with a short enough time out can cause the fast continuous flashing of L-13 as the bootloader itself keeps getting reset. If that might be the case one can try the manual hold down the reset switch while then hitting upload and only releasing the reset button when the compiling is completing and the upload is starting, takes a little practice but it does work.

Another possible solution to the same problem is to burn the Uno's bootloader to the nano board. Once that is done you would then always select the Uno board selection from the IDE board menu.

3

Thanks!

Those are really good ideas.

I neglected to say that I have tried the reset trick. It's really hard to say anything other than it didn't work... not that it couldn't have, depending on the exact timing, phase of moon, how I held my mouth.

So, are you saying that the Uno bootloader does handle WDT? I could undertake that, since I know that ICSP does work...

Any other ideas on how to disable (even momentarily) the WDT?

Daniel

4

polypagan:
Thanks!

Those are really good ideas.

I neglected to say that I have tried the reset trick. It's really hard to say anything other than it didn't work... not that it couldn't have, depending on the exact timing, phase of moon, how I held my mouth.

So, are you saying that the Uno bootloader does handle WDT? I could undertake that, since I know that ICSP does work...
Yes Uno bootloader properly handles WDT interrupts.

Any other ideas on how to disable (even momentarily) the WDT?
The manual reset method does work. I've purposely loaded a fast WDT to an only mega1280 board with a 20ms timeout in a sketch and created the same high speed L13 condition. Holding down the reset and only releasing at the correct time resulted in being able to load a new sketch.

Daniel

5

Retrolefty,
You are a god!

I breadboarded a nicer reset switch than the one on the Nano's PCB and it worked the first try!

And I was getting ready to burn the Uno bootloader, but now that won't be necessary, at least this time.

I suspect you're right: my errant code may have tickled the WDT causing very fast resets.

Thank you!

6

I "broke" a UNO and a Nano with a sketch that used a lot of RAM. Sketch worked fine on a MEGA

The UNO was fixed by just loading a new sketch but my Nano has the very fast blink as described. I am going to try to reload the bootloader but haven't got around to doing that yet.

Roger