Usbasp: programming a ATTiny2313A

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

Hi - I'm trying to program an ATTiny2313A (not 2313), but can't find the device type in AVRDUDE

The device list in AVRdude has the 2313 (not the 'A' suffix) -

 

  t2313 = ATtiny2313      [C:\WinAVR-20100110\bin\avrdude.conf:8735]
 

If I use the 2313 as in:

 

avrdude -c usbasp -p t2313

It doesn't recognise the device (wrong signature)

AVRdude only includes the 2313 (is there a newer version of AVRDude?

Thanks 

Russell

 

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

The Tiny2313A has the same Signature as the Tiny2313.   Your "old" avrdude version should work fine.

 

Your quoted command should work with a Chinese USBASP.    With a new Tiny2313A running on its RC clock.

 

Please copy-paste the actual command with actual response from avrdude.  

 

David.

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

I dunno ifthe A has a different signature as David says, but:

6.3 seems to be the latest version of avrdude:

 

http://download.savannah.gnu.org...

 

The "A" is not listed explicitly in "avrdude.conf", which is a human readable text file.

So if your signature is different you can add it to that file.

 

But please post your exact command & response.

 

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

2313A has the same Signature as 2313.

 

Please do NOT add "your Signature".     Do NOT use -F.

 

Just tell us what was reported by avrdude.

 

David.
 

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

Thank for the replies:

I think my programmer (or connections are a problem)

The 2313 and 2313A signatures are the same according to the datasheet 

I get inconsistent responses:

C:\Users\Richard>avrdude -c usbasp -p t2313

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x000102
avrdude: Expected signature for ATtiny2313 is 1E 91 0A
         Double check chip, or use -F to override this check.

avrdude done.  Thank you.

C:\Users\Richard>avrdude -c usbasp -p t2313

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.

C:\Users\Richard>avrdude -c usbasp -p t2313

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e910a
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: To protect your AVR the programming will be aborted

avrdude done.  Thank you.

Tried again - and this time ok:

C:\Users\Richard>avrdude -c usbasp -p t2313

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e910a

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

If I do it again I get:

C:\Users\Richard>avrdude -c usbasp -p t2313

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e910a

avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: lfuse changed! Was de, and is now 80
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: hfuse changed! Was df, and is now 0
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: efuse changed! Was fe, and is now 80
Would you like this fuse to be changed back? [y/n] y
avrdude: safemode: and is now rescued
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

Last Edited: Mon. Sep 4, 2017 - 09:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

russellsher wrote:
0x000102
As Atmel signatures all start 0x1E then that is just "noise". Like you say this looks like an intermittent wire or something.

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

It looks like a bad wire.
I suggest that you always use proper 5x2 header or 3x2 header with adapter.
This will give reliable results with your USBASP.
Random wires pushed into ribbon connectors are not a good idea.
.
David.
.
Edit. I see there is no SCK warning message. Chinese firmware sets SCK automatically and always gets a warning.
No warning suggests that you have German firmware that needs a -B5 argument.
Chinese firmware is far safer.

Last Edited: Mon. Sep 4, 2017 - 09:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

russellsher wrote:
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.

 

david.prentice wrote:
Chinese firmware is far safer.

After reading the "cannot set SCK" for the n-th time I gave in and replaced the Chinese firmware with the original Fischl.

(Which I had to debug a bit (Tnx for the source) because of a small slip in the reset timing).

 

Except for the obvious wiring there may be other problems.

Excessive noise because of bad or no decoupling caps.

Programming bitrate may be right on the edge between "working" and "not working"

There may be a damaged pin (ESD) so the logic levels are not proper (Check with a scope).

 

Can you easily swap some hardware to exclude hardware errors such as blown pins?

(For programmer & for the target) although the programmer is less likely because of protection series resistors (If your programmer has them).)

 

But at least this has convinced me that the error has nothing to do with avrdude, avrdude.conf or the signatures by itself.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Hi - I can access my board with a atmega16 (avrdude -c usbasp -p m16)  - no problem

I can use an AVRISPMKII to access the ATtiny2313A board reliably.

Now I only get:

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.

Whenever I try the Usbasp and my board- I have swapped out attiny2313A's

Yes, it may be nose - the only other thing is that the attiny board is 3v3 (target supplied - no jumpers in the Usbasp)

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

Chinese USBASP have either got a jumper for 5V/3V or a solder-bridge.
It will work fine at 3V. I would not be happy with a 5V USBASP and a 3V target.
Yes, you can remove the jumper so that the programmer does not supply power but I would only use that with a 5V target.
I always supply power with the USBASP. Generally 3.3V
.
David.

Last Edited: Mon. Sep 4, 2017 - 10:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I use the AVRISP MKII to disable the CKDIV8 fuse , then I can can read the signature using the USBASP 

 

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

 

Using a shorter ribbon cable also seems to help

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

russellsher wrote:
If I use the AVRISP MKII to disable the CKDIV8 fuse , then I can can read the signature using the USBASP
Did you see David's comment about using -B5 when using German firmware in the USBAsp ?

 

The fact that running the AVR faster "solves" the problem suggests the SCK is close or above the 1/4 speed requirement.

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

Ah yes- Perhaps I read the comment a bit too quickly the first time though - in fact I reprogrammed the firmware to get rid of the SCK warning.

So maybe I should try with a -B5 setting (Specify JTAG/STK500v2 bit clock period (us).) -- does the STK500V2 imply the SCK setting?

 

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

I am amazed by the people who install inferior firmware because they dislike the warning.
Yes, the 2011 German firmware works. But you have to set an appropriate SCK rate.
.
I see no reason to change the Chinese firmware unless you want to add some extra functionality.
I can program several 8051 variants with different Reset polarities.
Or if I want to program the brain-dead Tinys.
.
You can criticise the Chinese for not making the auto-SCK appear to be manual. i.e. lie
Or you can criticise avrdude for the message.
You can DEFINITELY criticise avrdude for the -F message.
.
But at the end of the day, avrdude is an excellent but of software that I would trust 10x more than other programming software especially GUIs. And you can rely on it working on Windows, Linux and MAC.
.
David.

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

From the Avrdude user guide:

-B bitclock
Specify the bit clock period for the JTAG interface (JTAG ICE only). The
value is a floating-point number in microseconds. The default value of the
JTAG ICE results in about 1 microsecond bit clock period, suitable for target
MCUs running at 4 MHz clock and above. Unlike certain parameters in the
STK500, the JTAG ICE resets all its parameters to default values when the
programming software signs off from the ICE, so for MCUs running at lower
clock speeds, this parameter must be specified on the command-line.

IS this not only for JTAG programming then? 

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

I have a feeling the software has moved on a little quicker than the manual has (a common problem!).

 

BTW if you are ever in doubt about such things the great thing about open source software like avrdude is that it is open source so you can take a peek inside and see where -B actually applies ;-)

Last Edited: Mon. Sep 4, 2017 - 02:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks - by the way (this may be obvious but...) where the reference info which relates the number suffixing -B to the actual clock speed that is then set?

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

No,  from memory -i is for bit-banged LPT port.

And -B is for intelligent programmers.  e.g. STK500, STK600, ATMEL-ICE, ..., AVRISP-2, ...

 

The original ?2007 fischl  firmware used a SLOW jumper.

The current 2011 fischl firmware understands -B

 

The PDF on my PC (c 2010) also says:

 

The AVR Dragon is supported in all modes (ISP, JTAG, HVSP, PP, debugWire). When
used in JTAG and debugWire mode, the AVR Dragon behaves similar to a JTAG ICE mkII,
so all device-specific comments for that device will apply as well. When used in ISP mode,
the AVR Dragon behaves similar to an AVRISP mkII (or JTAG ICE mkII in ISP mode),
so all device-specific comments will apply there. In particular, the Dragon starts out with
a rather fast ISP clock frequency, so the -B bitclock option might be required to achieve
a stable ISP communication.
The USBasp ISP and USBtinyISP adapters are also supported, provided AVRDUDE
has been compiled with libusb support. They both feature simple firwmare-only USB
implementations, running on an ATmega8 (or ATmega88), or ATtiny2313, respectively.

To be honest,  I have never used a -B switch with JTAG.

But -B is very necessary with ISP on slow targets.

 

Chinese USBASP owners never need to worry about SCK speed.    (until they change the firmware)

 

Some programmers e.g. STK500 will remember the settings in EEPROM.    Of course,   programming software can often b*gger it up.

 

David.

Last Edited: Mon. Sep 4, 2017 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Source has this:

 

https://github.com/sigmike/avrdu...

 

so it is "us". So presumably -B5 means a 5us clock pulse? In turn that means 200kHz which would be right for a 1MHz AVR (the clock needs to be 250kHz or less so 200kHz would be about right).

 

-B4 would presumably mean 250kHz but that is "borderline" depending on whether it is exactly 1Mhz or possibly a little below (1MHz int RC is inaccurate).

 

(-B6 would be 166.6kHz but that is probably over cautious).

Last Edited: Mon. Sep 4, 2017 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting - elsewhere on the forum I saw:

.... when I give this command

-c usbasp -p m32 -P usb -B 20.96 this is the response

 

avrdude.exe: set SCK frequency to 32000 Hz

and

 

-c usbasp -p m32 -P usb -B 20.96 this is the response

 

avrdude.exe: set SCK frequency to 32000 Hz
avrdude.exe: AVR device initialized and ready to a

not quite in agreement. 

Last Edited: Mon. Sep 4, 2017 - 02:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just tried: (with result)

C:\Users\Richard>avrdude -c usbasp -p t2313 -B5 -u -U flash:w:Bluetooth_Module.hex

avrdude: set SCK frequency to 187500 Hz
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

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

The -B argument gives a period value in us.   e.g. -B20.96 is 20.96us which means <= 47.7kHz

 

The actual hardware programmer can only achieve certain discrete SCK frequencies.   i.e. 32kHz is actual frequency used.

 

So you could say -B 31.25 and still get 32kHz.

-B 31.26 would get the next lower SCK frequency.   Probably 16000Hz

 

your -B5 suggests <= 200kHz.

the USBASP has an internal 12MHz crystal.   So 187.5kHz is the result.

 

Most humans will never bother with the decimals unless they are wanting > 1MHz.   e.g. -B0.5 for 2MHz

 

David.

Last Edited: Mon. Sep 4, 2017 - 02:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As I say, the joy of open source:

 

https://github.com/sigmike/avrdu...

 

That is where -B is processed. The strtod() will accept floating point and create a float value. Next the code does this with it:

 

https://github.com/sigmike/avrdu...

 

So 5.0 now becomes 5000000. In the USBAsp support:

 

https://github.com/sigmike/avrdu...

 

Almost the first thing it does is "set sck period" which is here:

 

https://github.com/sigmike/avrdu...

 

It then tries to match something suitable in a table:

 

https://github.com/sigmike/avrdu...

 

So it just tries to find the nearest match in:

 

static struct sckoptions_t usbaspSCKoptions[] = {
  { USBASP_ISP_SCK_1500, 1500000 },
  { USBASP_ISP_SCK_750, 750000 },
  { USBASP_ISP_SCK_375, 375000 },
  { USBASP_ISP_SCK_187_5, 187500 },
  { USBASP_ISP_SCK_93_75, 93750 },
  { USBASP_ISP_SCK_32, 32000 },
  { USBASP_ISP_SCK_16, 16000 },
  { USBASP_ISP_SCK_8, 8000 },
  { USBASP_ISP_SCK_4, 4000 },
  { USBASP_ISP_SCK_2, 2000 },
  { USBASP_ISP_SCK_1, 1000 },
  { USBASP_ISP_SCK_0_5, 500 }
};

The 187500 you got is one of the entries there.

 

PS forgot to mention that the entries in that table are defined in the .h file here:

 

https://github.com/sigmike/avrdu...

Last Edited: Mon. Sep 4, 2017 - 02:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the help - I'm going to recheck the CLKDIV in the fuses and then play with slowing the clock to see if that solves the original problem.

 

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

Yes, your been lock it !! so read out signature is : 0x00 0x01 0x02.

To solve this problem is simple, just ignore signature and force execute Chip erase command , and ... all come to  normal 

 

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

Sorry,  I'm confuse at90s2313 & attiny2313a, but look like at90s2313 the situationcheeky

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

Above NOT TRUE for Tiny2313 or TIny2313A. Just checked. Spec sheet specifically says that signature can be read when the device is locked. Checked because of other current thread with similar Tiny2313(A) signature problems.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net