ATtiny2313 signature 0xffffff, why?

Hi,

I bought new ATtiny2313. I put it on breadboard, conect all for bit-banging and all is working ok. First blinking program works well.

Then I tried to add crystal 16MHz and programmed lfuse to 0xEF. This disables CKDIV8, so I get really 16 MHz because I've changed C code too - #define F_CPU 16000000UL. All was ok.

The problem. Without crystal I sent program examples more times. All was okay. With crystal I sent program only one time. At second attepmpt avrdude tells me that signature isn't right. Now it is 0xffffff.

Then I used -F switch to ignore signature check. All is working okay. But when I program lfuse back to it's default value (0x64) and remove crystal, I send blinking program for 1 MHz. It is blinking twice in a second. Then I check calibration bytes. They are 0xff 0xff, but they must be 0x5b 0x5a. So it seems that mc is working at 2 MHz without calibration codes, isn't right?

So, how I can get back signature and calibration bytes?

Two days I surfing internet and digging throuh google. It seems, that no one has the same problem. I think it happened because of lost contact on one of pins (reset, sck, miso, mosi) at the time, when I program it when it running at 16MHz. Anyway I cannot understand, how is it possible. All is working okay, if I put OSCCAL=0x60 row in program code at very start. Then I have 1MHz with CKDIV8. But anyway I think it's not normal that mcu have lost his calibration code and signature.

Is it possible that these codes cannot be read at one speed, when fuses can be read at the same speed? I tried all speeds and no result.

People, please talk to me! :) I feel like Robinson alone on island :D

I've had this problem. Check ALL your connections. I had MOSI and MISO switched around. Then, make sure the resistors on the cables are all of the same value. Finally, if you're still having problems, probe your port that you're using to program the micro.

oh yeah, I hadn't done any bitbanging (I'm still trying to figure out what the heck that means), I was just using a parralel port cable.

Since you are using a ATTINY2313 and not an Arduino, I would recommend that you ask some questions on the avrfreaks forum. You are more likely to get accurate help there.

http://www.avrfreaks.net/

My suggestion is: use a "real" ISP. The avrispmkII is recommended. Unless you have a lot of expertise you will waste a lot of time searching for strange issues. Once you have sufficient expertise you will own an ISP anyway. Bit banging is something from the days when ISPs were very expensive or if you forgot the ISP somewhere. An ISP is typically faster and more reliable.

Udo

Thank you for your replies!

No, I allways was on that way that I create tools for my self. I don't want to pay to someone if I can do the same and it is very interesting for me. And important too!

There is no problems with bitbanging. And I like to control all I do, which isn't possible with popular equipment. Okay, now I use Arduino as programmer because I don't have FTDI chip yet to create small addon for my breadboard. And Arduino allways was and will be as fast experiment board. http://www.indigo.lv/avr/ - my bitbang cable and last picture - my workplace.

After this bad issue with ATtiny2313, I (with fear ofcourse) tried to program ATmega328P - the new chip I bought, not that which on Arduino board. The result is very good. No problems with speeds, fuses, signature, calibration and reprogramming. All is working perfectly.

I think there was some problems with ATtiny2313 (one of million!). Maybe therefore Atmel recommends to use new version with sign "A"? http://www.atmel.com/dyn/products/product_card.asp?part_id=3229 Not recommended for new designs: replaced by ATtiny2313A

Then I check calibration bytes. They are 0xff 0xff

How do you know? I never could figure out how to read the calibration bytes.

There's a document on Atmel's web site that describes how to set a processor's calibration. According to the documentation, AVRDUDE has support. I tried calibrating a 2313 and, like you, I had strange things happen. In the end, I have no idea if the calibration was or was not changed.

Badly, enter the terminal mode!

avrdude.exe -t -p t2313 -c diecimila -P ft0 -B 4800

when in terminal mode, you type: read calibration (can be shorten - read cal). Or read these bytes to file:

avrdude.exe -p t2313 -c diecimila -P ft0 -B 4800 -U calibration:r:calibration.bin:r

it creates file calibration.bin with 2 bytes in it.

I will check Atmel's website, but I think there will be the same what I've done - at the start of program (in C) I set calibration:

OSCCAL = 0x60;

0x60, because without calibration bytes and without crystal and with CKDIV8 there was not 1 MHz as it was befre "crash", but some 1,7 MHz. So standard 0x5B (I don't know why) don't give me 1 MHz - I've checked with chronometer :) So I increase until I had 1 MHz.

But if you want to read calibration from program, then you must read the same OSCCAL register.

With crystal all is running okay, because for external clock and resonators there is no need for calibration. So only signature is missing, but for that I use -F switch for arvdude. It ignores this mistake and continues sending data as it is with normal signature.