howto: flash ATtiny with AVRDude and command prompt

I think it works if you do the flash quickly enough or something? Pretty sure I’ve flashed with the offtime cap in place before, but I don’t do much flashing.

Cereal_killer says the capacitor shouldn’t be an issue, only if the pin is grounded by a resistor or bridge to ground

I believe you can slow down the baud rate in writing in order to compensate for irregularities or issues

I do believe I might have gotten a lot of cheap Chinese ATtiny’s at $0.40 a pop from Aliexpress and for the life of me can’t write to em…I believe like TexasPryo has said…they may have their fuses locked :frowning:

It depends upon which pin is used for the off-time cap.

Basically anything that connects to processor pins 5,6,7 or even 1 can mess up programming. Star 3 (pin 5) connected to ground is a definite no-no.

You are probably OK with AMC7135’s connected to the PWM pin (pin 6). Large FETs can have enough gate capacitance to interfere with programming.

And you can pretty much forget programming drivers that don’t have a series reverse polarity protection diode (unless you disconnect the LED… even that may not always help).

All the BLF drivers have the off-time cap on pin #2, no issues with flashing them with that still in place. Same goes for the zener-modded drivers with a resistor in place of the diode. But if the diode is replaced with a jumper, it's a no-go. All the FET drivers flash just fine as-is.

They're only $0.53 from Digikey... as long as you buy 1000 at a time. :(

Eh. You probably do not have ATiny’s at all there - since neither functioning counterfeits nor bad batches are known to exist you may well have received dummy counterfeits. That would be my guess. EDIT: by which I mean to say that it doesn’t make any sense that you’d receive raw chips with the fuses locked. You’ve probably got dummies.

probably so, I do think I got a few of em to flash…but the ones I put on my first run BLF15 and 17DD’s just won’t flash…fooey

Ooh, I didn’t notice the parameter to change the baud rate! I’m going to have to try that next time I’m flashing a finicky chip.

Hmm, actually, I’m not sure that works. It looks like that might not apply to the usbasp device. Will have to try it to be sure.

They won’t flash when you take them off and put them in your ZIF socket?

:slight_smile:

yup yup

Thanks

Hi,

I’m hoping for some advice on programming an attiny.

I have tried with 2 chips - both have similar problems. Both are from fasttech attached to nangj 105c.

When I run “avrdude -p t13 -c usbasp -u -e”, the result looks as described in the initial post (ie, good outcome).

When I run “avrdude -p t13 -c usbasp -u -Uflash:w:jcapstandard.hex:a -Ulfuse:w:0×75:m -Uhfuse:w:0xff:m”, I get:

c:\avrusb>avrdude -p t13 -c usbasp -u -Uflash:w:jcapstandard.hex:a -Ulfuse:w:0×7
5:m -Uhfuse:w:0xff:m

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e9007
avrdude: NOTE: “flash” memory has been specified, an erase cycle will be perform
ed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: reading input file “jcapstandard.hex”
avrdude: input file jcapstandard.hex auto detected as Intel Hex
avrdude: writing flash (662 bytes):

Writing | ################################################## | 100% 0.70s

avrdude: 662 bytes of flash written
avrdude: verifying flash memory against jcapstandard.hex:
avrdude: load data flash data from input file jcapstandard.hex:
avrdude: input file jcapstandard.hex auto detected as Intel Hex
avrdude: input file jcapstandard.hex contains 662 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.61s

avrdude: verifying …
avrdude: 662 bytes of flash verified
avrdude: reading input file “0Î75”
avrdude: invalid byte value (0Î75) specified for immediate mode
avrdude: read from file ‘0Î75’ failed

avrdude done. Thank you.

The hex file was created using amtel studio, with SRK_no_ramp_1.0.c.

I am completely new to this, so my mistake could be a simple/obvious error.

Thanks for any help you can offer.

-Ulfuse:w:0×75:m -Uhfuse:w:0xff:m

If you copied that line of text from a post here, please note that one 'x' is an actual 'x', but the other one is some weird superscript 'x' that avrdude cannot understand.

It’s recommended you crate a batch file (.bat) which you can run instead of typing in the command sting each time. It will execute all flashing / er ace commands as well as setting the fuse bits.

Thankyou! I got the line from the download link in the first post. Once I changed out the bad ‘x’, the output looks like it should - at least for my brand new chip. The chip on the driver I have stripped the 7135’s from, and mounted to my SRK driver is no longer responding. I get:

c:\avrusb>avrdude -p t13 -c usbasp -u -e

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: error: programm enable: target doesn’t answer. 1
avrdude: initialization failed, rc=–1
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

Is that a sign this chip is probably gone bad? I’ve wiggled the clip and tried multiple times. But the new chip always works, and the old one never. If it is gone, at least I have one success.

Thanks again.

Yes I was using a batch file, but for some reason it would always give an error when I ran it. When I cut and pasted the separate commands from the batch file, all was good (so I was not actually typing it, i was cutting and pasting).

Thanks.

There are physical things that can happen to the driver that will prevent it from flashing. D1 diode shorted/bypassed/etc., one of the 'stars' grounded (they should all be clean/not bridged for the STAR momentary firmware), a bit of solder stuck somewhere it shouldn't be...

I doubt its bad, if its bad it’ll usually give a verification error or it will initialize several times and nothing else. Your not getting a connection at all. Are you hand soldering? Just a single extra drop of solder on one leg can keep the entire chip from making connection with the clip. I would say take some solder wick and suck all the extra off all the leg’s and try again. You could also solder flying leads (with female jumper ends) directly to pin 1,4,5,6,7 and 8 and try that.

Typing on phone so I missed comfy’s above post, like he said a shorted pin can cause a no connection (RC=–1) error. You can flash with an off-time cap in place (it’s not a short) but you can not flash with any stars grounded.

It was communicating with this chip initially, and I haven’t made any changes to the driver at all (it was mounted on the SRK driver before I started trying to program it). But I will double check it and make sure there is nothing physical happening like you say. Thanks.

OK. Thanks, if you don’t think it is bad, I will persevere with it. I didn’t actually mount the chip, I am using it on the nanjg 105c. I guess I could use a multimeter to ensure each pin is connecting correctly.

When struggling with Nanjg 105D (8*AMC7135) flashing and no problems at all with Nanjg AK-47A (3*AMC7135) I realized that AMC7135 load level on pin 6 of ATtiny13A is responsible. Just cut the track before flashing and it WILL work.

It complicates the process but you can make it simpler elsewhere. FT Convoy pill actually does not have to be soldered to Nanjg 105D (8*AMC7135) driver…

8)