ATTINY programming failed after CLKPR (SOLVED)

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

Hey guys,

I'm having a strange problem here, and I would ordinarily just throw out the offending part, but it's in an SMT design of mine.

I'm working on a project that needs to use the internal clock to about 8MHz on my ATTYIN261. I have been working on it successfully for a long time, modiftying my program, reprogramming and testing. I decided to slow things down.

My code was originally

	CLKPR = 0x80;	/*Setup CLKPCE to be receptive*/
	CLKPR = 0x00;	/*No scalar*/

I modified it to

	CLKPR = 0x80;	/*Setup CLKPCE to be receptive*/
	CLKPR = 0xF0;	/*No scalar*/

Realizing that this wasn't going to help, I "fixed" it

	CLKPR = 0x80;	/*Setup CLKPCE to be receptive*/
	CLKPR = 0x05;	/*No scalar*/

Sure enough, it slowed the part down, but now the part won't program.

I can only get:


# avrdude -c usbtiny -p t261 -U flash:w:test.hex  -F

avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATTINY261 is 1E 91 0C
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.

Note that the processor still sails along happily running the code I put on it earlier, slow. Also, if I assert the reset pin, the processor does reset.

Is there any known issue with changing the CLKPR bits? Can I put the programmer in to slow burn mode or anything? Do I have to spend the hour de-soldering and replacing the part?

Thanks in advance.

Last Edited: Sun. Mar 8, 2009 - 09:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You will need to reduce the ISP frequency to 1/4 of your oscillator divided by the prescaler whatever that is.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Is there any way to forcibly tell the tinyisp to "go slower" from a high level, say terminal commands? I don't think it's possible to modify the ISP's fuses to go slower, because then I doubt it would work on the computer-end.

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

SOLVED!

my line was:

avrdude -c usbtiny -p $(PROGPART) -U flash:w:test.hex 

As soon as I did:

avrdude -c usbtiny -p $(PROGPART) -U flash:w:test.hex -B 1024

It took 10 seconds to burn, but worked wonderfully!!! Thanks for the suggestion!

Now, I can program the part at full speed since it woke up with the right CLKPR.

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

So it is 8 years since the above post.  But I am grateful that this exists.  The simple mention of the "-B 1024" allowed me to get going again.  I have been attempting to reset fuse bits for days now thinking that was my problem.  Like CNLohr above, I too was playing with the CLKPR register and caused my two of my Attiny85 dev boards (like these) to freeze.  I think it was setting CLKPR = (1<<CLKPS3) that killed it for me.  Since then I've been on an odyssey in search of a solution.  I do not understand how this may have rendered these dev boards unusable.  From what I have read it has something to do with the relative speed of the target MCU (Attiny85 in my case) and the programmer (I'm using both USBasp, and ArduinoISP).  

 

But what allowed me to get my blinky-test-program going again in Avrdude was the command: ...avrdude -CC:\...avrdude.conf -v -pattiny85 -c arduinoisp -U lfuse:w:0xe2:m -B 1024

and the distinquishing part is "-B 1024".  Many forum entries would have you rebooting firmware (to solve "target not found") and a number of other tricks but the simple 1024 did it.

 

Ultimately I was able to reprogram my dev boards in Arduino IDE and am now trying to do this in Atmel Studio 7, only I am tripped-up on another problem: "could not find USB device with vid=0x16c0 pid=0x5dc vendor='www.fischl.de' product='USBasp'"  

 

Perhaps this limited success will be of use to others.  The message is to 

Craig

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

CLKPR sets the system clock prescaler.  The part that bites most users in the butt is that changes to CLKPR persist until the AVR is >>released<< from reset, rather than until it >>enters<< reset.  So, if your AVR powers up, starts executing code, gets to the instructions which tickle CLKPR, and >>then<< you try to upload new code via ISP, the system clock prescaling will remain in place, even though ISP places the AVR into reset.  ISP requires that the programming clock be < 1/4 of the prescaled system clock, so if you prescale the system clock such that it is too low for your programmer, ISP will fail.

 

There are two ways out of this dilemma.  One is to reduce the programming clock as you have done, in your case with avrdude's -B option.  The second is to ensure that the AVR powers up in reset, and never comes out of reset, before you attempt the ISP session.  That way, the AVR will power up with a /1 prescaler (or a /8 prescaler if CKDIV8 is programmed) and stay that way because your code never gets a chance to tickle CLKPR before your ISP session starts.  The easier way is to change programming clock.

 

One way to avoid this in the future is to place a short delay in your code before you tickle CLKPR.  Say, a couple of seconds.  That way, the system clock will stay at its power-on default of /1 (or /8) long enough for you to start an ISP session.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Thank you!  Fantastically clear explanation - even I can understand it... I think.  So by stuttering the program by a few seconds I can create a reset window that will allow reprogramming to occur before engaging CLKPR.  My programmer is an USBasp from LC Technology and has a jumper that also gives a low speed options for programming.  I did that, but the -B option is what rescued me.  I will experiment with that right at my next chance.

 

Odd thing for me was that setting                          CLKPR = (1<<CLKPS1), and

                                                                           CLKPR = (1<<CLKPS1|1<<CLKPS0),

enabled me to continue to reprogram.  But setting  CLKPR = (1<<CLKPS3),

stopped me cold.  How would the first two CLKPR cases enable me to reprogram, but the third case be different?

 

Thanks again. 

 

Craig

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

Have you understood how CLKPR works?  The clock is divided by 2CLKPR

 

So this:

CLKPR = (1<<CLKPS1);

... divides the clock by 2(1<<CLKPS1), which is 2(1<<1), which is 22, which is 4.  With an 8 MHz oscillator, the system clock will be 8/4 = 2 MHz.  The maximum ISP clock will be 1/4 of that, or 500 kHz.

 

And this:

CLKPR = (1<<CLKPS1) | (1<<CLKPS0);

... divides the clock by 2(1<<CLKPS1) | (1<<CLKPS0), which is 2(1<<1) | (1<<0), which is 22 | 1, which is 23 which is 8.  With an 8 MHz oscillator, the system clock will be 8/8 = 1 MHz.  The maximum ISP clock will be 1/4 of that, or 250 kHz.

 

But this:

CLKPR = (1<<CLKPS3);

... divides the clock by 2(1<<CLKPS3), which is 2(1<<3), which is 28, which is 256.  With an 8 MHz oscillator, the system clock will be 8/256 = 31.25 kHz.  The maximum ISP clock will be 1/4 of that, or 7.8125 kHz.

 

The default programming clock will depend upon your programmer, but is often 125 kHz.  Too fast for the last example.  Using -B 1024 increases the clock >>period<< to 1024 us, or 1.024 ms.  That gives a programming clock of 976.5625 Hz, which is low enough for all of your examples.

 

In truth, some programmers manage this automatically, and specifying -B does nothing.  Some programmers ignore it entirely and use a fixed programming speed.

 

From the datasheet, with your three examples highlighted:

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Aug 30, 2017 - 12:51 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again.  Got it.  I knew about the 1:4 timing ratio between CPU and programmer, but I didn't know about the common programmer speeds, nor did I do the math.  If I may paraphrase what I think I learned from you: my first two cases allowed for the programmer to remain active, but the third example closed the door on the programmer due to the speed... unless I provided the 2 second, or so, window to permit the programmer to gain a reset position.

 

Datasheet writing is impressive, but your description is far more clear.  I've read the Attiny85 datasheet many times, but never concluded the exponent math as you described.  So again paraphrasing, presuming my USBasp programmer is a 125 kHz device, and applying the 1:4, then the minimum effective1 CPU speed would be 500 kHz, or a clock division factor of 24, or 16, on a 8 MHz device - without having to employ the 2 second stutter delay.

 

Note 1/.  Only today did I learn that #define F_CPU ?000000 has no impact on the CPU speed but does inform the compiler and is presumably reflected in the resulting 'effective' assembly code.  All of this brought me almost too close to understanding fuse settings and CKDIV8.  But I'll save that for another day.  It does leave me wanting to understand how power-saving low frequency programs can be deployed with conventional programmers that are 'too fast' for this.  I presume the answer lies in ... the fuses. 

 

Thanks again for your generous explanations. 

Craig

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

but never concluded the exponent math as you described.

It is evident from an examination of the table I posted in #8.  Many other prescalers in the AVR share a similar exponent-like relationship with their mask bits, although somewhat modified.

 

nor did I do the math

Always do the math.  While my wife reminds me often that I'm a freak (pre-dates my arrival on these fora) because I like math, it is also (one of the things which) makes the world go round.  Don't be afraid of it.

 

2 second stutter delay.

Remember that this is just one work-around I proposed.  The other is to ensure that the AVR stays in reset after a power-up before initiating ISP.  This precludes the possibility of any code running, including the code which changes CLKPR.

 

Only today did I learn that #define F_CPU ?000000 has no impact on the CPU speed

Correct.  It merely tells the compiler (rather, AVR Libc) what speed you >>think<< the AVR is running at.  The compiler will believe you, and any arithmetic which depends upon F_CPU will blindly obey.  Baud rate calculations, delay loops, etc.  If you have lied to the compiler by telling it one speed, but setting fuses and I/O registers to realise a different speed, then you get what all liars deserve ;-)

 

 

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

While I too enjoy math, sometimes I fail to completely consume tables.  The datasheet authors have a tough enough job, but I would prefer a simple formula rendering of the table.  Maybe exponents are too difficult for some datasheet readers despite the binary power of 2 logic under it all.

 

Yes, the math makes the world go around.  However, it thoroughly annoys my friends, and wife, when I bring the math to discussions of economics and... gulp... national finance (in the US).  Amazing how few people are actually counting the details.  Bless the mathematician and the journalists that spread the truth!  So now I've wondered far astray of the topic.  

 

Thanks for the help. 

 

 

Craig