Is my AT85 bricked? Can it be recovered?

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

Folks,

 

While working on an earlier project, I bought 10 AT85's.  I bricked a couple while doing that project, but I recently started a new project, and in the course of an evening, I have lost another two chips.  I only have 3 left. 

I'm pretty sure I know what I did wrong.  The effect is that I program a chip (a small test program to check something or other.  It works.  I modify the program and try to re-write it, but it says that the fuses have been set to zero.

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x000000 (retrying)

Reading | ################################################## | 100% 0.03s

avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
avrdude.exe: Expected signature for ATtiny85 is 1E 93 0B
avrdude.exe: safemode: hfuse reads as 0
avrdude.exe: safemode: efuse reads as 0
avrdude.exe: erasing chip
avrdude.exe: reading input file "0xE4"
avrdude.exe: writing lfuse (1 bytes):

Writing |                                                    | 0% 0.00s ***faile
d;
Writing | ################################################## | 100% 0.09s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xE4:
avrdude.exe: load data lfuse data from input file 0xE4:
avrdude.exe: input file 0xE4 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

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

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0000
             0x00 != 0xe4
avrdude.exe: verification error; content mismatch

avrdude.exe: safemode: hfuse reads as 0
avrdude.exe: safemode: efuse reads as 0
avrdude.exe: safemode: lfuse changed! Was e4, and is now 0
Would you like this fuse to be changed back? [y/n]

I'm using Atmel Studio-7, and tools/External tools  AVRDude commnd line is ...

 

-U lfuse:w:0xE4:m -U hfuse:w:0xdf:m -e -v -F -pattiny85 -cstk500v1 -PCOM6 -b19200 -D -Uflash:w:"$(TargetDir)$(TargetName).hex":i -C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"

I think I know what I did wrong, but I'd like your assurance that it would produce the effect I'm getting, and maybe a friendly shovel to dig me out.

 

In writing the test program, I set all port pins to OUT except INT0, which I'm going to use.  "All pins" includes PB5, which is used for RESET, and the Arduino Nano that I'm using as a programmer needs to yank that line in order to program the chip.

main:
; Load stack register
LDI R16, HIGH(RAMEND) ; Upper byte
OUT SPH,R16 ; to stack pointer
LDI R16, LOW(RAMEND) ; Lower byte
OUT SPL,R16 ; to stack pointer

; Define directions for port pins
ldi r16,(1<<PB0)|(1<<PB1)|(1<<PB3)|(1<<PB4)|(1<<PB5)  ; <==== I guess this is the problem.  PB5 = Reset
out DDRB,R16   ; Set all ports OUT except INT0 (PB2)

 

My questions :

Q1 : would this produce the effect I'm seeing?

Q2 : Has it really set the fuses to 00, or does it just think so because it is unable to pull the RESET line?

 

I now have four bad chips, of which two (and maybe all) have the same issue, so ...

Q3 : Have I stuffed them?  I guess I can't even supply an external clock to a pin set as output.

 

Thanks People.

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

Oh look. It's another -F.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

Tell us more about E4 in lfuse. What on earth made you pick that value? ISP now has to be 32kHz or less. Suggest you read my "locked AVR" tutorial and start injecting a clock into XTAL1

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

+1 on Brians observation.

 

What on earth makes all these people have a -F on the AVRDUDE commandline?!

 

"Hey, I'm an inexperienced driver about to do a manouvre with my car that I'm no master of. I'll just unlock my seat-belt and turn off anti-break-lock and anti-skid before doing that..."

 

Seriously, what is it that makes this -F occur all the time? Is there some web-site out there recommending it? Could we get a link (so that we possibly could post a comment there recommending never  to use -F unless you know exactly what you're doing and why you want that -F) ?

 


 

For picking good fuse values, Mark Hemmerlings online fuse calculator is a great help: http://www.engbedded.com/fusecal

 

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Johan you know the Internet where "a little information can be dangerous". So a mate of a mate tells you that his sister's boyfriend was having avrdude problems but got it to work with -F (he didn't of course but he happened to wiggle the dodgy connection just before he coincidentally tried -F and it worked) . So now I am trying to program an AVR and I "know for a fact" that -F helps (no idea what it means but it definitely helps). I try it and programming works so I write all that down in my blog. 17 people read they blog, they each recommend it to few friends who all do the same. Suddenly I've had more than 1,000 hits. 23 of the people who read it mention it in their own blog as "good advice". The Google Web crawling robots hit most of the blogs during the night and notice this one blog with "avrdude" in the title has 23 independent links to the article. So now when you Google "avr avrdude" it's actually the 5th hit. So more people read it and link to it as the "definitive solution". The robots notice this additional activity. Now it's the 4th listed hit.

 

Thanks goodness for that initial advice about -F or none of this would ever have happened. (still don't actually know what -F does though!) 

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

Why was -F in my command line?  It's easy to explain.  When I started on my last project, about a year ago, it was my first ever contact with programming a microprocessor, so I was totally dependent on what I was told by those in the know - and I don't actually know anybody that does.  I learned what I could by reading websites about the AVR chip and how to program it.  The Instructables website, at

http://www.instructables.com/id/... ....  says ...

Open Atmel Studio 6.

Go to Tools>External Tools

Fill in the fields as the picture shows. The Command field is to be filled with the location avrdude in your machine, in my case: C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe

As to the Arguments field, fill in with the following line:

-U lfuse:w:0xe6:m -U hfuse:w:0xd9:m -e -F -v -patmega328p -carduino -PCOM2 -b19200 -D -Uflash:w:"$(ProjectDir)Debug\$(ItemFileName).hex":i -C"C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"

At that point, I did not even realise that the command string was to be passed to AVRDude.  I thought it was a commnd to AS-7 to tell it what to do with the target.

Well, I learned those things along the way, but I managed to get my project made, and as I wasn't having trouble with the command string, I never queried it or changed it.  It seemed to work.

You guys have a lot of experience, so you spotted the -F right away.  I don't, and wouldn't have been able to. 

 

You're right about me being "an inexperienced driver about to do a maneuvre with my car that I'm no master of."  However, I have had instruction to click the anti-break-lock switch before I start.  Clearly, I need further help.  The field of microprocessors is so big that you might as well say to somebody who asks a question "Why don't you know this?  It's in Wikipedia!"  Also, I'm unlikely to kill myself or anybody else by using -F.  Before you are let loose in a car, you have to take a driving test.  Writing to this forum is, in many ways, my test - and if I am found wanting over and over, well, I learn bit by bit - but I really need help, not criticism.  Well, the -F has been pointed out, so I have looked it up, and will remove it from the string.

 

Now, if you'd suffer me to do so, I'd like to repeat my questions.

 

Q1 : would this (the RESET line being set as output) produce the effect I'm seeing?

Q2 : Has it really set the fuses to 00, or does it just think so because it is unable to pull the RESET line?

Q3 : Have I stuffed my chips?  I guess I can't even supply an external clock to a pin that is set as output.

 

If I have, they weren't very expensive, so it's not the end of the world - but I'd like to recover them if it's relatively easy.

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

armstack wrote:
The Instructables website, at http://www.instructables.com/id/... ....  says ...

Thank you for the link. I'll pop over and see if a comment can be made..

 

EDIT: Nope.. You need to log in, and I won't do that. If someone else can and wants to comment, I suggest something like this:

 

WARNING! Never, NEVER, use the -F switch unless you know exactly what you're doing and understand the possible consequences. The -F switch incapacitates checks that you've selected the correct AVR model, andd results in AVRDUDE "blindly" programs your chis as if it was the one you've selected on the AVRDUDE command line. If it actually isb't (e.g. you've made a typo on the command line) then it might render your AVR "bricked" (impossible to program) and hard to resurrect from that state, possibly requiring a "parallel programmer" (a quite rare type of programmer these days - your programmer most likely isn't one of those).

 

REPEAT: Never, NEVER, use the -F switch on the avrdude command line. If you're having trouble programming your AVR then there is a fault somewhere and -F is not the solution!

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sun. Oct 29, 2017 - 03:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Johan,  I'll do that, and also give a link back to this thread.  Check the link again in a few minutes to see my update.  However, although this is one site that gives -F as a parameter, it's only one site.  That's where I got it from, but I'd bet there are plenty others.  For example, if I had been making a writeup somewhere of how I did my project (a soft-start for a 240V motor), I would probably have propagated that line because I wouldn't have known any better, so it is quite likely that there are other websites that give it.

 

Any ideas about my questions?

 

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

Cliff answered your questions in Post #3.

 

JC

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

armstack wrote:
I would probably have propagated that line because I wouldn't have known any better

You should not write about things you do not master. (At least not "being imperative".)

"He used to carry his guitar in a gunny sack, or sit beneath the tree by the railroad track. Oh the engineers would see him sitting in the shade, Strumming with the rhythm that the drivers made. People passing by, they would stop and say, "Oh, my, what that little country boy could play!" [Chuck Berry]

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

armstack wrote:

Q1 : would this (the RESET line being set as output) produce the effect I'm seeing?

 

No. To use Pin1/PB5 as an output you have to disable the RESET functionality in the fuses.

 

Quote:

• Port B, Bit 5 – RESET/dW/ADC0/PCINT5
• RESET: External Reset input is active low and enabled by unprogramming (“1”) the RSTDISBL Fuse. Pullup is
activated and output driver and digital input are deactivated when the pin is used as the RESET pin.

 

armstack wrote:

Q2 : Has it really set the fuses to 00, or does it just think so because it is unable to pull the RESET line?

 

See the reply to Q1. Your RESET line is not affected by your code. As to the fuses, see post #3 about your maximum ISP clock.

 

armstack wrote:

Q3 : Have I stuffed my chips?  I guess I can't even supply an external clock to a pin that is set as output.

 

You can supply a clock if your fuses have ended up set to external clock. If your fuses are still on internal clock then you don't need an external clock to recover the chip but again see post #3 regarding your maximum ISP clock.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

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

"You should not write about things you do not master. "

I didn't.

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

My apologies.  It was a question.  I should have responded.

 

"Tell us more about E4 in lfuse. What on earth made you pick that value? ISP now has to be 32kHz or less. Suggest you read my "locked AVR" tutorial and start injecting a clock into XTAL1"

 

lfuse bits :

7 = CKDIV8 - I don't want that, so set it to 1 (unprogrammed)

6 = CKOUT - I don't need to see it, so set to 1

5 = SUT1  - used the default value of 1

4 = SUT0  - used the default value of 0

3 - 0 - I want a 128kHz clock, so used "0100"

 

On a previous chipo, I set lfuse to A4 so I could see the clock, to check it was the right frequency.  It was, but although that chip still works, it is no longer programmable.

 

Consequently, lfuse = E4

 

"Suggest you read my "locked AVR" tutorial" - I already had.

"start injecting a clock into XTAL1" - I got that from the tutorial, and tried it, but it didn't seem to work.  That's why I asked "Q3 : Have I stuffed them?  I guess I can't even supply an external clock to a pin set as output."

Maybe I can, but I didn't have any success with my attempt.  The clock was from another AT85 I had previously programmed and had available, but I think the output was too slow.  I don't know what frequency the ISP uses (I take it ISP is In System Programmer?).  It's an Arduino Nano, and there is a frequency on pin D9 of 500Hz, but it doesn't look like a clock.  The frequency is stable, but the mark-space is constantly varying from 10% >> 80% >> 10% about once per second.  No other pin has a frequency on it while it's at rest, and the programming cycle doesn't last long enough for me to check all the pins.

 

I read a bit about the -F, and as far as I can tell, it protects me against putting in the wrong kind of chip - but as I am not doing that, it shouldn't have made any difference.  Correct me if I'm wrong, but it seems that AVRDude picks up the signature from the chip, which says "I'm an AT85", and compares it with what the command line says it is - "

-pattiny85

and gives an error if it's wrong - but I assure you, the chip in my programmer is an AT85.

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

Soprry, should have mentioned...

"ISP now has to be 32kHz or less."

I think it must be, then, as it still programs the chip when those fuse settings are used - but it only programs it once.  After that, it is unprogrammable.

Last Edited: Sun. Oct 29, 2017 - 06:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My point was this: E4 selects 128kHz WDT as clock source. ISP must always be at 1/4 speed or less so by picking this clock you have now set the AVR so it requires ISP at 32kHz or less (1/4 of 128). You *may* be able to slow things down using -B on avrdude command but this will depend on your programmer. If it can't be slowed down you have a problem. 

 

I wonder what the attraction of 128kHz is in the first place? Is this about battery operation and lowering energy usage. Most experience here seems to suggest that waking up for a very short blast of fast operation makes little difference to waking for a long burst of slow operation as you appear to be trying for with the choice of 128k. So what makes you want to use this if it will cause problems with ISP? 

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

Thanks for this, but the programmer is working, and the chip is doing what I wanted.  The problem is that this is a project in process, so I will be reprogramming the chip several (possibly many) times, and at the moment, it only programs it once.

 

Let me give you an example.  When I decided to use a 128k clock, I wanted to check that that's what I was getting, so I set the fuses to 0xA4.  I checked the clock output and it was correct, so then I wanted to move on to the next stage.  I made a few mods to the program, but discovered I couldn't write them to the chip because of the error given above.  However, I still have that chip, and if I put it into the breadboard, it still gives me a 128K clock on pin 3.  The chip is still working, but I can't program it.  Now, having done a bit of reading and a bit of thinking, I thought it was because I set pin 1 (PB5) to an output in DDRB, so that would prevent the ISP from pulling its logic level, which would prevent it from programming the chip.  However, Brian Fairchild (#11) says "To use Pin1/PB5 as an output you have to disable the RESET functionality in the fuses", and I didn't do that - and I certainly didn't mess with RSTDISBL.

 

AHA!  Moment of enlightenment (?)

 

Brian also mentions the ISP clock, and it is only now, as I write, that the penny has dropped, that the chip was running with its native 1MHz clock the first time it was programmed, so I guess it is my clock frequency at fault.

 

I have been experimenting to establish what frequency the programmer is using.  I'm 'programming' an empty chip socket.  When AS-7 gets to the point of declaring that the fuse has gone to 00 - "Do you want to change it back?", I answer Yes, and it tries continually to do so, and I can look at the signals.

MOSI has a signal on it, but it's very jittery, and I can't make much sense of it

Pin 7 has a nice signal on it, however.  It shows a series of pulses, 4uS TRUE, 4uS FALSE (8uS/cycle = 125KHz).  The series lasts 250uS (probably 32 cycles), and repeats every 6mS

 

So it looks like my frequency is 125KHz, and Clawson already said it should be 32kHz or less.  I'll look at the -B option for AVRdude.  Thanks.

 

OK Guys, unless you have something more to say about it, I guess I know what I need to do.  And what not to do.

Thanks for all your help.

 

Incidentally, FYI, the application is for a 240V timer.  I have a tendency to leave my garage lights on, and not to discover it till next time I need the car, which can be a week.  I also leave my coffee machine on for hours at a time.  The timer will not have any display, but will be programmable with a single button for a number (1-65535) seconds.  Its readout is a beeper, and another pin drives a transistor that closes a relay.  I know that timers can be purchased, but it's a project.  I like doing little projects - and I have some spare AT85's.

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

Still don't understand the 128k choice. Makes little sense. 

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

Incidentally, FYI, the application is for a 240V timer. 

Still don't understand the 128k choice. Makes little sense.  

 

Agreed.  Using that clock is simply asking for trouble!

As you are switching 240 Mains objects, you can obviously power your timer off a small wall wart, so battery savings, (an entirely different topic, and your clock selection may well not offer any energy savings), really isn't an issue.

 

Bottom line, just run on the internal RC Osc at 1 or 2 or 8 or whatever MHz the default is for the micro you select.

Your life will be much easier.

 

BTW, I did a similar project a few years ago.

The "trigger" was a temperature sensor to turn on/off a roof heater.

I added an LCD as:

1) It was helpful for code debugging

2) They are very cheap these days

3) One could easily see when the target device was on or off, where it was in the timer interval, the number of power cycles it had been through, etc.

4) One could also see the current outside temperature, which was the trigger for this system.

 

Be careful with Mains wiring within the same box as your project.

Drop one screwdriver or mis-place your fingers and you can have a bad day!

 

Good luck with your project.

 

JC

 

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

Thanks DocJC.  "Using that clock is simply asking for trouble!" - I entirely accept what you say.  This is all part of the learning process - when I did it, I didn't know there was anything potentially troublesome with a low clock rate.  It's in the datasheet, so it seemed reasonable to use it.  As the application is all low frequency, it seemed a good idea to use a low frequency clock.

For example, I wanted approx a 1mS timer to base everything around - debounce, timings, etc.  128kHz div 64 gives a 0.5mS period, and 128kHz div 256 gives a 2mS period, and I can use either of these.   Such a pulse is easy to develop by clocking a counter with the system clock and setting a 1-byte number into a compare register.  In fact, if I used div 64 and PWM mode, it would count up in 0.5mS and down in 0.5mS, so I'd have my 1mS period.  It seemed convenient, that's all.  I know that I can scale the counter/timers, and that's what I'll do now, but at the time of starting out on this project, I didn't have the knowledge I have now.

 

I thought of using an LCD - as you say, they're less than £2, but I wanted to use a single button.  Also, the AT85 only has 5 usable legs if I keep away from the RESET pin.  One of them will be my button, one will be the beeper, one will be the relay, so I didn't have many left for the TWI -  though I could have done away with the beeper, I guess.  I've been thinking for a while about a door lock with a single button on it, so you would tap out a tune on it, and if you get it right, it opens the door, or if you don't, it rings the doorbell.  And out of that idea, came my one-button timer.  Yes, the LCD could help in  debugging, but I'm not expecting too much trouble there (famous last words).  After all, it's a pretty simple device.

 

I have been going through the AVRDude command line options, and I'm quite puzzled by them.  Can you help?

I have     -e, which causes a chip erase to be executed.  Resets flash ROM and EEPROM to value ‘0xff’.  Clears all lock bits.

Then I have    -D, which disables auto erase for flash.

Is there a conflict there, or do the options combine so as to clear lock bits and reset EEPROM, but not erase flash?  I can't see the sense in that.

 

BTW, I think there may be another error in my command line.  The chip type is specified with  -pattiny85.  Looking at the spec for the AVRDude command line, I think it should be -pt85.  If anybody knows for sure, please let me know.

Last Edited: Mon. Oct 30, 2017 - 01:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All reasonable assumptions, and having played with some chips you now know its usually better to use a higher freq clock! 

Lessons learned!

 

Next bit of advice:  Don't mess with the Reset\ pin.

Use it for it's primary purpose, resetting the micro.

If you absolutely need one more pin... then get a larger device!

When you have lots of micro development experience, and are working on a huge commercial product with many, many units, then let's chat about using the Reset\ pin as an I/O pin.

 

You can, or course, use a software USART transmitter to transmit logic level serial data out a single pin.

You can use a slightly larger micro as a "back-pack" on an LCD, to receive the incoming serial data and display it on the LCD.

Sometimes useful for debugging even if it doesn't remain within the final design.

 

Finally, I've never used AVRDude, so I'll let others comment on those questions.

 

JC

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

armstack wrote:
BTW, I think there may be another error in my command line. The chip type is specified with -pattiny85. Looking at the spec for the AVRDude command line, I think it should be -pt85. If anybody knows for sure, please let me know.

 

Well, in my experience, both work. Apparently, avrdude goes to the conf file and tries to match the string you gave to either "id" or "desc" fields. Then it reads the signature from the chip and sees if it is the correct one (compares to the "signature" field).

 

excerpt from avrdude.conf:


#------------------------------------------------------------
# ATtiny85
#------------------------------------------------------------

part
     id            = "t85";
     desc          = "ATtiny85";
     has_debugwire = yes;
     flash_instr   = 0xB4, 0x02, 0x12;
     eeprom_instr  = 0xBB, 0xFF, 0xBB, 0xEE, 0xBB, 0xCC, 0xB2, 0x0D,
	             0xBC, 0x02, 0xB4, 0x02, 0xBA, 0x0D, 0xBB, 0xBC,
	             0x99, 0xE1, 0xBB, 0xAC;
## no STK500 devcode in XML file, use the ATtiny45 one
     stk500_devcode   = 0x14;
##  avr910_devcode   = ?;
##  Try the AT90S2313 devcode:
     avr910_devcode   = 0x20;
     signature        = 0x1e 0x93 0x0b;
     reset            = io;
     chip_erase_delay = 400000;