Have I just locked myself out of my ATTiny?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry for the dumb question, but here is my problem:

 

I (stupidly) flashed a program that effectively disables the serial port(s), by configuring all port D bits as outputs.

Since then, AvrDude stubbornly refuses to flash new programs into my ATTiny (using the default USB link).

I understand the UART is needed for these uploads, but I was wondering if there was a way out of this deadlock, maybe some trick to let the bootloader take control by hard-wriring some pins or something?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How about a model number?  A board name?  A link?  Something?  My crystal ball is in the shop.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well an Arduino Nano board, with an ATmegal 328. Any Arduino board works the same as far as bootloader is concerned, I suppose?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any Arduino board works the same as far as bootloader is concerned, I suppose?

No.  Different boards ship with different bootloaders.

 

You've contradicted yourself:

Since then, AvrDude stubbornly refuses to flash new programs into my ATTiny

Well an Arduino Nano board, with an ATmegal[sic] 328

Which one are you having trouble with?

 

Configuring pins on port D (or any other port) as outputs on the Nano should have no effect on your ability to bootload.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry, I was using an Arduino to test a bit of code meant to run on an ATTiny, and I just got confuded between the two. I was testing the software on Protheus for awhile, then I decided to download it to the Arduino Nano to make sure it worked as intended, but I forgot to change the configuration to leave the Rx/Tx pins free.

The progamming went OK but since then I just no longer can progam the Arduino. I launch AVRdude, it gives me some protocol error 10 times and eventually fails. Resting the board while AVRdude attempts to program it does not seem to make any difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Were you using the nano's bootloader with a USB-to-TTL adapter?  Or were you using a programmer and ISP?

 

Post the output of your attempt to upload code onto the nano, including the exact command you're issuing and all of avrdude's output.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I'm using the USB adapter. The ISP does not use a bootloader anyway, right?

 

command:

 

avrdude -Cavrdude.conf -v -patmega328p -carduino -PCOM3 -b57600 -D -Uflash:w:whatever.hex:i

 

avrdude.conf is the default configuration file shipped with the v1.8.3 Arduino IDE.

 

output:

 

avrdude.exe: stk500_recv(): programmer is not responding

 

avrdude.exe: stk500_getsync() attempt 1 of 10: not in sync: resp=0x00

avrdude.exe: stk500_getsync() attempt 2 of 10: not in sync: resp=0x1e

avrdude.exe: stk500_getsync() attempt 3 of 10: not in sync: resp=0x3f

avrdude.exe: stk500_getsync() attempt 4 of 10: not in sync: resp=0x86

avrdude.exe: stk500_getsync() attempt 5 of 10: not in sync: resp=0x9e

avrdude.exe: stk500_getsync() attempt 6 of 10: not in sync: resp=0x98

avrdude.exe: stk500_getsync() attempt 7 of 10: not in sync: resp=0x66

avrdude.exe: stk500_getsync() attempt 8 of 10: not in sync: resp=0x78

avrdude.exe: stk500_getsync() attempt 9 of 10: not in sync: resp=0xf3

avrdude.exe: stk500_getsync() attempt 10 of 10: not in sync: resp=0x9e

 

avrdude.exe done. Thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A Nano comes with USB connector and bootloader. There is no need to ever use an external programmer.
When you do, it destroys the Nano's bootloader and ruins the Arduino functionality.
.
To recover: connect the ISP programmer. Burn Bootloader from the Arduino IDE.
Remove programmer. Dig hole. Bury programmer.
.
Be happy. Your Nano is alive and well. It will work like it was new.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The avrdude command seems correct (although you do not need the '-D' option).  Are you sure you have the correct com port?

 

When avrdude opens the com port the nano is supposed to reset and run the bootloader.  When it resets, you should see the 'L' LED flash, and then the TX/RX LEDs flash as communications begins.  Is this happening?

 

I assure you, making port D an output will have no effect on bootloading.  Something else is going on.  What else does your sketch do?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I removed the Arduino from the breadboard to make sure nothing was interferring with the signals, and still got the same errors.

The fact that avrdude started seems to indicate there were no problems with the COM port.

Clearly the board failed to reset, since I could not see the characteristic led blinking.

 

I finally managed to get the thing working, after plugging and unplugging the USB connector quite a few times.

 

What I don't understand is why avrdude failed to reset the board. It is supposed to use the DTR signal from the USB->serial interface to drive the reset pin, right?

So my guess is the problem was either caused by some other piece of software sending garbage on the COM port or an electrical fault on the board (some faulty soldering or short circuit).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is supposed to use the DTR signal from the USB->serial interface to drive the reset pin, right?

So my guess is the problem was either caused by some other piece of software sending garbage on the COM port or an electrical fault on the board (some faulty soldering or short circuit).

Those are two possibilities, yes.

 

Has the issue disappeared altogether, then?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I even re-flashed the program that disabled the serial link and it went like a charm. It was just a nasty coincidence that lead me to believe the software had something to do with the problem.