Hi,
Tried with fuses:
lfuse:w:0xff:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
But according to the datasheet it should be:
lfuse:w:0xf0
After programming this value I got:
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
What is wrong ? (HW is ok because I can read or program other T45)
Thanks
potzli:
But according to the dataset it should be:
lfuse:w:0xf0
What "dataset" are you talking about? lfuse:w:0xff looks correct to me:
potzli:
What is wrong ? (HW is ok because I can read or program other T45)
Do you have a crystal connected correctly to the ATtiny45?
pert:
What "dataset" are you talking about? lfuse:w:0xff looks correct to me:
Sorry the the autocorrector put dataset instead of datasheet!!!!
pert:
Do you have a crystal connected correctly to the ATtiny45?
Yes of course because with lfuse = 0xFF it works. But after check with the fuse calc with 0xF0 it say: "undefined preset 7". I used this one
AVR® Fuse Calculator – The Engbedded Blog . It don't say that is not valid...
potzli:
Sorry the the autocorrector put dataset instead of datasheet!!!!
Would you mind specifying what part of the datasheet made you think 0xf0 is correct? Perhaps break your logic bit by bit.
potzli:
Yes of course because with lfuse = 0xFF it works.
Oh, I see what you're saying now. You mean that it doesn't work with the lfuse:w:0xf0. I thought you were saying that it didn't work with lfuse:w:0xff.
potzli:
But after check with the fuse calc with 0xF0 it say: "undefined preset 7". I used this onehttp://www.engbedded.com/fusecalc/ . It don't say that is not valid...
"undefined preset 7" essentially does mean that it's not valid.
Datasheet, p.30
CKSEL3:1 = 111
CKSEL0 = 1
SUT1_0 = 0
Seems not impossible (with ceramic crystal) ... Probably I missed something !
Yes it works with 0xFF
The most curious think is why after programming 0xF0 I got:
avrdude: Device signature = 0x000000
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.
???
I see the problem now. 1 means unprogrammed and 0 means programmed. So in the fuse calculator you need to uncheck the checkboxes for the bits that are set to 1 and check the checkboxes for the bits that are set to 0. You did just the opposite and that's how you got the 0xF0 value.
You're right!! I didn't see this small comment and strange logic!!!
Does it explain why uC are dead (?) after my false fuse programming ?
Is only the issue with a HV programmer to get those uC back to life ?
I don't know how you can recover the chips. I suppose a HV programmer is worth a try. Maybe someone else here will have an answer for this.
Thanks for your help pert !!!