Invalid signature

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

Hi,

I'm new to avr's and im stuck with this problem. I have at90s2313 connected to the breadboard, and it has a 10MHz ceramic oscillator with builtin caps, Three led's and one button. It is connected to comp via dt006 style home-made cable which has 390ohm resistor's on all pins exept gnd.

Now the problem is that when i trye to program it thru avrdude it says invalid signature 0xffff. It worked fine before and only change that i made before uploading was one comment in the code. I use fastavr for the code.

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

Tell avrdude to ignore the signature.

As everyone has figured out by now, the signature and calibration rows are quite eraseable, and transmission errors on the link can hit the bigger-chiperase command. I've even mapped it out for Tiny13, and can write any signature/calibration data I like to it.

A better quickie-cable for the SPI programmable parts:
Take a 2.0 meter 9-conductor 50 mil pitch ribbon cable, and on the PC end attach all odd conductors to GND. Insert 3k9 in SCK,MOSI. Reset gets 200 ohms in series and 2.2nF to GND before entering the cable. On the target end insert 100 ohms in the MISO conductor, and tie ALL the odd wires to GND. Finally scavenge an EMI ferrite tube off an old VGA cable and feed the programming cable through it.
This takes care of the most common problems (write glitches, reflections, and ground noise), and is, in my experience, a severe reliability improvement over something like the STK200 cable.

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

I have been trying different switches in avrdude like -F -V , and it still wont work. Is it possible to have broken uC dispite that avrdude regonizes it?

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

Ok, spoke too fast :) that -F switch worked. So do i allways just but this switch when i upload or is there some way to fix this problem. And thanks for your help.

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

KPP, would you mind posting information on how you managed to write your own signature and calibration values to the device? I'd be very interested...

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

This is via the HV programming logic; If someone maps it out on the other methods, I would like to learn too.

To erase the signature and calibration rows, modify your programming software so that bit7 of the first instruction byte of chiperase is set. That is, the sdi/sii pairs
80,CC 00,64 00,6C
Will erase the signature and calibration rows.

Before attempting this, read out ALL 16+16 bytes of signature and calibration. The documentation states that 2 bits in the second pair of read_sig_byte are address bits; This is untrue, there are 4 address bits for T13. Likewise for read_cal_byte, the second pair has 4 address bits.

After you have erased the signature and calibration rows, load the flash programming instruction, followed by 16 words of data as one usually would for programming flash. Then, instead of executing flash_load_high_address_page_program, load
sdi 1xx1 x011 0000 0000 0000 0000
sii 0101 0101 0100 0101 0011 0101
instead (let's call it sig_page_program).
The low bytes end up in signature, the high bytes end up in calibration.

And the calibration value written here IS used after reset. The higher undocumented sig/cal bytes may or may not have interesting control functions :-)

The method employed for this was brute force; I had a program fire off one random sequence after another, checking the chip state after each sequence. It spat out a number of interesting patterns, and I then had to figure out what part of the pattern was significant. Beware: Like the documented keep_eeprom_during_chiperase fuse, there is also an undcumented bit somewhere, 'keep signature rows during chiperase'; During some of my experimentation I managed to erase it on one of my devices and I haven't been able to find it, thus every time I do a normal chiperase the signature of this particular device is erased too.

edit: my bit patterns are given without 0_ and _00 padding.

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

At the risk of sounding like a total and utter geek, that is facinating. Atmel have to put in the signature and OSCCAL bytes somehow - I wonder how many other undocumented functions are avaliable!

I can see applications for the above immediatly. You could set the OSCCAL byte to a unique serial, or use it in the rest of the program as a limited hacker protection. Or perhaps not.

I think one day i'll have to start experimenting....

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!