Generic USBASP with avrdude working first time only after USB connection for ATtiny1634

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

I just wanted to share a problem I ran into and a quick solution for it.

 

When using a generic USBASP with an ATtiny1634, communication with the device would only work for the first avrdude command issued, and would fail for every command after that. Read, write, scan, whatever. I could only use the device again if I disconnected and reconnected it. As you can imagine, it got a little annoying after a while.

 

In my case, it turns out that adding "-B12" to the avrdude options worked around the problem. Lower values didn't work reliably, and higher values did, but are slower.

 

For whatever reason, the first access to the device works fine at the default speed, but subsequent accesses don't. Running at a slower speed all the time was less of a burden than manually disconnecting and reconnecting all the time.

 

There might be better ways around the issue (USBASP firmware upgrade maybe?), and it might be some quirk of my own environment, but this served as a quick and easy workaround for me. If you run into a similar problem, it might be worth a shot.  It might be worth trying a higher "-B" value and then adjusting downward from there until you get the right mix of speed and reliability.

 

The same adapter worked fine for an ATtiny84A and ATtiny40. So, I'm guessing that certain combinations of USBASP and MCU might exhibit this behaviour.

 

I hope this helps.

 

Here's the error message without this option so that it shows up in searches:

avrdude: auto set sck period (because given equals null)
avrdude: error: program enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
         Double check connections and try again, or use -F to override
         this check.

 

Last Edited: Fri. Oct 6, 2017 - 06:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

It's a bug in the usbasp firmware. Look here: http://www.avrfreaks.net/comment/838359#comment-838359

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

Interesting! Thanks for the link. Looks like a great resource for anyone looking for more information or a better solution than the one presented here.

 

(Myself: I can't risk messing with the firmware on my USBASP until I've established a secondary way to program the 1634. It's a cheap clone so I'm not expecting much from it. Thankyou for the wealth of information.)

 

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

You gave me a shock.   The Tiny1634 is 5 years old.    The "current" Fischl firmware is 6 years old.

 

IMHO,  Chinese USBASPs arrive on your doorstep for $3.   The Chinese firmware works 100%.   I see little point in changing anything.

Most of them can be used for 3.3V or 5V.    Either a jumper or solder-bridge.

 

David.

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

Mine's a cheapie bought about a year ago. Seems to be a different design, no jumpers, space that might take a voltage reg. So there's at least one out there with this problem. I wonder which firmware the working ones are using if not the Fischl one. Could there be a popular fork out there with this issue fixed?

 

Link to the Fischl firmware page for anyone exploring:

 

http://www.fischl.de/usbasp/

 

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

Most Chinese firmware is locked.   Most of them set the SCK frequency automatically.

 

This is how I recognise "good Chinese firmware" i.e. by the SCK Warning message from avrdude.

Of course the warning could be from pre-2011 fischl firmware but this is pretty unlikely.

 

I would be very surprised to see any Chinese clone running fischl firmware but it is not uncommon for AvrFreaks members to replace Chinese with German firmware.

 

David.