Most ATTiny10 Internal Oscillator Much Slower Than Datasheet

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

I am having an issue where we need to have our ATTiny10's operate at about 12 MHz.  The datasheet indicated we'd probably have some headroom... But, on the AVRs I've tested so far, we can't even get to 12 MHz at all...

 

Another weird thing is the factory calibrated 9.6 MHz mark seems totally bogus, waay too low. For instance, the [[EDIT: It is an 8 MHz clock. I got this confused with the Tiny13, still annoying that they're all on the low end.]]

Processor 1: 176, 7.811 MHz

Processor 2: 160, 7.731 MHz

Processor 3: 136, 7.788 MHz

 

Shouldn't the internal cal be 9.6 MHz?  Could I be using the chip wrong?  Do I have to configure something differently? [[EDIT: Was supposed to be 8 MHz, not 9.6 so that's OK... But still the chips are performing pretty slowly]]

 

     //Used for frequency test, programmer writes desired OSCCAL value into 0xfe.
    OSCCAL = pgm_read_byte( 0xfe );
    CCP = 0xD8; //Enable CCP.
    CLKPSR = 0; //Go for 8 MHz operation.

 

I've verified to make sure that these values are correct... For processor 1, with the configured OSCCAL value, I get 0.1286us per cycle, or 7.772MHz:

 

 

These tests are from 5V runs... But it only seems to get worse as the voltage goes down!

 

 

Very different from the datasheet.

 

 

 

What is going on here?!?

 

 

 

 

Last Edited: Wed. Nov 7, 2018 - 05:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
pgm_read_byte( 0xfe ); 

Eh? Surely that reads byte 254 from the flash memory? If the Tiny10 is 1K doesn't it have flash all the way from 0 to 1023 ?

 

While you may well be able to use LPM to read the OSCAL calibration byte I'm pretty sure it's not mapped to that location.

 

(off to check the datasheet in case these brain dead tiny's have some weird kind of memory map...)

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

OK, so there is some "weirdness" in these devices. I remember now that because the data sections are all so small it has room to map everything into a linear address map accessible with LD/LDS. But it looks like this:

 

 

That still doesn't have calibration bytes at 0xFE.

 

Also, assuming a direct read then I do hope that pgm_read_byte() for these devices knows it just has to apply an offset presumably a pgm_read_Byte(0xFE) actually maps to a linear LDS read at 0x40FE ?

 

EDIT: reading on. So it says:

 

 

So why would you have to mess with OSCCAL if it's going to autoload the calibration value into OSCAL at power on anyway?

 

EDIT2: Also just checked pgmspace.h it has this:

 

 

also:

 

 

Which appears to just be doing a LD from N + 0x4000

 

So why did you use pgm_read_byte() for this?

 

Last Edited: Wed. Nov 7, 2018 - 05:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would expect it to work straight out of the box with the Factory Calibration.

 

I am surprised that anyone who chooses a Tiny10 cares about the frequency.

 

Please post your code.    I suspect that you are doing something to frustrate the Factory Calibrated RC.

 

David.

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

CNLohr wrote:
Shouldn't the internal cal be 9.6 MHz?

Now you are going to make me open the datasheet -- all your other graphs and such say/hint at 8MHz...

There are no mentions of 9.6MHz in the datasheet.  Are you thinking of Tiny13?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

CNLohr wrote:
Processor 1: 176, 7.811 MHz Processor 2: 160, 7.731 MHz Processor 3: 136, 7.788 MHz

Even your 7.73MHz is only -2.7% for 8MHz.    Sounds pretty reasonable to me.

 

Most Mega and Tinys come out of the Factory with good calibration.    Much better than the datasheet limits.

 

David.

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

(1) 9.6 MHz -> Well, that's what I get for working on two customer's AVR projects at the same time.  Indeed, the other project was an ATTiny13.  I was getting those two confused.

 

(2) Reading that data byte works, and has nothing to do with the issue.  Yes, there's several other ways I could have skinned that cat, but, I can change that without any problems... It's how the graphs are made.  The tool https://github.com/cnlohr/pi_tpi just edits that byte of flash, sequentially incrementing it to generate the graph. https://github.com/cnlohr/pi_tpi... I am just wondering if there's some other "trick" to getting some extra umph out of the processor Is the code that I'm using to do the tests.

 

I am still worried about getting to 12 MHz.  It is possible we may just trash all the AVRs that can't make the 12 MHz cut, and rework new AVRs on to them, and keep going until we have enough boards.  Thankfully this project only needs 60 boards.

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

IIRC the factory calibration is done with VCC = 3v but I may be wrong on that.

The RC osc is will vary with VCC voltage to some degree, along with temperature.

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

CNLohr wrote:
It's how the graphs are made.

As your results with your tool are quite different than the graph in the datasheet, I'd examine that result, as you hinted.  I'm not a Tiny10-family person.  perhaps another 'Freak can run a similar test.

 

[edit]  Instead of using the "tool", if you take your simple test program in #1 and have OSCCAL set to a hard value instead of reading the factory cal number, e.g. OSCCAL = 0xfc; and then get the 'scope trace, what does that show?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Nov 7, 2018 - 06:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CNLohr wrote:
I've verified to make sure that these values are correct... For processor 1, with the configured OSCCAL value, I get 0.1286us per cycle, or 7.772MHz:

???  Let's see then entire program, including generated code, that is producing this pulse train.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

why not set the CKOUT fuse bit and measure the freq there!

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

ki0bk wrote:
why not set the CKOUT fuse bit and measure the freq there!

Well, not being too well versed in that family -- it ain't your Daddy's fuse bit, is it?  "configuration register" and all that...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

theusch wrote:
Well, not being too well versed in that family -- it ain't your Daddy's fuse bit, is it?

I'm not either, but would "assume" his programming device would have a way to set that bit.

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

CNLohr wrote:

(2) Reading that data byte works, and has nothing to do with the issue.  

Err no, you are quite wrong about that. Read my analysis again. You are not, repeat NOT reading the calibration byte but some random code byte from your program that happens to locate to 0x40FE

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

Clawson:  My programmer https://github.com/cnlohr/pi_tpi... read/writes to that memory in order to control the OSCCAL for a specific run on of the AVR.  My programmer can read the calibration byte, and that's how I'm getting it read. Also, on on the ATTiny10, the system automatically reads the calibration byte at boot and sets the OSCCAL.

 

theusch: Using CKOUT is a really good idea!  That is a good way to know FOR SURE.  Here is it running at 12 MHz on a device I calibrated for 12 MHz, so it looks like once I do user-calibration it gets super accurate.  It's just frustrating that so many units stop shy of even 11 MHz!

 

 

Also, as thusch pointed out if anyone else can do some runs, that would be awesome!  This whole batch I have seems to be exceptionally slow, though I probably have enough ones that I can goose up to 12 MHz that it'll work out.  I really wonder if the RC oscillators in the batch I have are just lame :(.

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

After checking more of the AVRs in our batch, it looks like the first two were the worst offenders.  Right now we're at a roughly 90% success rate, which isn't the 100% I expected, but, that's A ok!!! 

 

Still mysterious why some are so slow... But, several others almost perfectly match the datasheet!

 

Thanks for the feedback, sorry for the franticness...

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

So it works at room temp, how do they do at 0c or 40c? 

 

Jim

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

From distant memory,   I think that I have tried the "whole range" of OSCCAL on a regular Tiny / Mega.

 

The datasheet graphs are just "Typical".   No Max and Min.   No guarantees.

 

The graph shows 4MHz- 15MHz as typical.    At a guess,  some units might give 5MHz - 18MHz.   And others 3MHz - 11MHz.

This would mean you could reliably calibrate for 7MHz or 10MHz.    100% success for 12MHz would be optimistic.   

 

Hey-ho,  does it really matter if you have a 90% success rate? 

 

From a practical point of view,   a reel is likely to be fairly consistent.    So you might have to reject a whole reel at a time.  What are you going to do with the reject reels?

 

Surely it would be safer to buy cheap in-spec MCUs from a different company.

 

David.

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

Normally the only thing that is guaranteed is that is that at any temperature and voltage there is a value where it will run 8MHz  

Last Edited: Thu. Nov 8, 2018 - 06:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why do you need to run them so far out of spec?

 

the osc is made to do well at 8MHz, and at that speed small changes in temperature and voltage will not make big changes.

 

 

add:

remember that @ 3V the max speed for the chip (even with external clk ) is 8.67 MHz ! (8 2/3)

 

 

 

 

Last Edited: Thu. Nov 8, 2018 - 06:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know it's a little off topic, but @david.prentice, what other options are there for _really_ tiny micros.  Everything else ranges from slower to atrocious (Like the PIC10f200, PIC10f322 (which takes 4-clocks-per-cycle)!).  Like yeah, there is the PMS150C which can run at 16 MHz, but it still takes several more cycles to do much of anything than an AVR, i.e. my ATTiny10 could run at 9 MHz and still beat it in a foot race.  It feels like there's just no options when you want to go sot-23-6.

 

Size is the big constraint, but I would pay $$$ for something a little speedier for our next rev. 

 

Being an shared-bus controller for strips of SK6812's.  Going slower = lower framerate, have to hit minimums.

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

but a sot-23-6 is 3x3 mm

 

for 1.5x1.6 mm you can get a ARM cortex (4x4 ball grid)

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

sparrow2 wrote:
Normally the only thing that is guaranteed is that is that at any temperature and voltage there is a value where it will run 8MHz

HOWEVER -- IME AVRs pretty much follow the Typical Characteristics charts.  Now, you sparkies need to tell me whether newer processes end up with much more unit-to-unit and batch-to-batch variations.

 

sparrow2 wrote:
Why do you need to run them so far out of spec? the osc is made to do well at 8MHz, and at that speed small changes in temperature and voltage will not make big changes

C'mon -- sour grapes.  OP isn't trying to run out of spec. 

Speed Grade:
0 - 4 MHz @ 1.8 - 5.5V
0 - 8 MHz @ 2.7 - 5.5V
0 - 12 MHz @ 4.5 - 5.5V
 

And the aim of the 12MHz is ~20% below the expected from the Typical curve.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

above 8MHz you need to use external clk (to keep spec)

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

sparrow2 wrote:
above 8MHz you need to use external clk (to keep spec)

Where is that specified?  I did not see it in the datasheet.

 

Are you making the assumption/extrapolation that since the default nominal spees for the internal oscillator is 8MHz, that any other value is verboten for some reason?

 

What if my batch of chips comes at e.g. 8.2MHz?  They don't work?

 

Pick an OSCCAL value.  Let's start with, say, 125.  Is it within spec to run the AVR with an OSCCAL value of 125?

 

What about 130?  140?  180? 203?  I.e., exactly which OSCCAL value determines that I am running out of spec?

 

I think you are extrapolating too much.  But you are the expert in thee things, so I'm probably wrong.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Nov 8, 2018 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok 8MHz +10% as always

 

Nothing new about this chip

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

sparrow2 wrote:

but a sot-23-6 is 3x3 mm

 

for 1.5x1.6 mm you can get a ARM cortex (4x4 ball grid)

 

BGAs are unworkable on aluminum PCBs and other arenas where one-layer boards* are problematic**.

 

* = This particular design is not a one-layer aluminum PCB, but, the solution needs to be portable to that domain.

** = technically could use an ATTiny44, as it has a one-layer-friendly configuration, but overall assembly tooling costs still go up.  When your bottom line counts and you have to get your stuff made at cheap Chinese factories, there is a wee bit more thought that needs to go into this sort of thing.

 

Could use the other 8-pin surface mount variants DFN-like but it's still an awkward solution. 

Fingers crossed that Microchip releases tiny versions of their new UPDI processors, but as of now, it's just an unusual niche that there are depressingly few options for.

 

sparrow2 wrote:

ok 8MHz +10% as always

 

Nothing new about this chip

 

Unfortunately for me, you are correct, apparently they do not guarantee the internal oscillator to >8.1 MHz :(

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

sparrow2 wrote:
ok 8MHz +10% as always

Satisfy my curiosity -- where does that figure come from?

 

The last place I looked was the OSCCAL register description in the Tiny10 datasheet.  Nothing like that there.

 

I guess that there is a hint in e.g. '88PA, "Frequency Range".

 

I'm reading that as "default"; I'm guessing you are reading it differently.  If it was so "out of spec" dire, you'd think it would be stated.  AVR053 app note has no such mention -- but it >>does<< give a chart with up to 15MHz, at least implying that it is possible/practical.  Arduino forums have activity on ramping up OSCCAL. 

 

Aha!  AVR054 has this note:

AVR054

5

2563C-AVR-04/08

a little bit from this description, because the MSB of OSCCAL selects one of two

frequency ranges as shown in

Figure 1-3. Within each of the frequency ranges (MSB

constant), version 5.x oscillators exhibit

the same pseudo-monotonic characteristics

as other versions of the oscillator.

Figure 1-2.

ATmega169 calibrated RC oscillator

frequency as a function of the

OSCCAL

value.

Figure 1-3.

ATmega169P calibrated RC oscillator frequency as a function of the

OSCCAL

value.

For all tunable oscillators it is important to

notice that it is not recommended to tune

the oscillator more than 10% off the base

frequency specified in

the datasheet. The

reason for this is that the internal timing in the device is dependent on the RC-

oscillator frequency.

I'll claim that this note is passe, as modern chips have e.g. separate WD oscillator, EEPROM timing, and ... what else?

 

[edit]  Continuing to search, I found an absolutely pertinent app note that I did not know about:  AVR057

http://www.yawp.com/ref-library/...

APPLICATION NOTE

Atmel AVR057: Internal RC

Oscillator Ca

libration for

ATtiny4/5/9/10/20/40

 

which says on the first page

Tune RC oscillator to any frequency within specification

I'm excited now -- gotta read further...

I find no note such as for earlier generations.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Nov 8, 2018 - 09:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CNLohr wrote:
Unfortunately for me, you are correct, apparently they do not guarantee the internal oscillator to >8.1 MHz

And you verified that where?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

I guess the specifics are a little up to the user for interpretation, but, I can imagine how Microchip would interpret it... (Sorry, I meant to highlight the 8.1 MHz, not the 10%)

 

Last Edited: Thu. Nov 8, 2018 - 09:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CNLohr wrote:
I guess the specifics are a little up to the user for interpretation

Yes, indeed.  The chart says "when aiming at a target frequency [about] 8MHz, you can get within 1%".  To me, it says nothing about what frequency can be reached with high OSCCAL value.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

at least in the old data sheets it worded with something like I wrote in #19

 

like a mega16 (it's a bit odd because it has 4 different calibration speeds where newer only have one calibration speed and then a divider) :

 

. Note that the Oscillator is intended for calibration to 1.0 MHz, 2.0 MHz, 4.0 MHz, or 8.0 MHz. Tuning to other values is not guaranteed

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

Are you using the extended temperature range parts?

 

Not sure if they could be slower parts or just shouldn't be run faster than 10MHz

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

Note: You are also limited by the logic analyzer sampling rate. This gives the final resolution of your measurement. Enable only one logic channel on and sample it using the highest sampling rate.

 

Try to measure the signal for several seconds and then add a measurement that calculates the average frequency. This will give you a more accurate result.

 

Here I have sampled an 8MHz from an STM32 evaluation board for several seconds:

Example

 

Last Edited: Thu. Nov 15, 2018 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is with the Logic Pro 8.  It's USB 2.0 FS, so it's got loads of room to spare!

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

CNLohr wrote:

I guess the specifics are a little up to the user for interpretation, but, I can imagine how Microchip would interpret it... (Sorry, I meant to highlight the 8.1 MHz, not the 10%)

 

Not really, specs are clear at 8MHz.  You are hoping to push up to 12MHz, which is well outside where they test/spec oscillator pull.

You may find the next batch of parts shifts on the yield curve.

 

With all this risk, you may be better to choose another micro...

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

Who-me wrote:

CNLohr wrote:

 

I guess the specifics are a little up to the user for interpretation, but, I can imagine how Microchip would interpret it... (Sorry, I meant to highlight the 8.1 MHz, not the 10%)

 

Not really, specs are clear at 8MHz.  You are hoping to push up to 12MHz, which is well outside where they test/spec oscillator pull.

You may find the next batch of parts shifts on the yield curve.

 

With all this risk, you may be better to choose another micro...

 

I would gladly.  Must be manufacturable on one layer, must be small, can't fit a SOIC.  I am unaware of any options.

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

CNLohr wrote:

Who-me wrote:

CNLohr wrote:

 

I guess the specifics are a little up to the user for interpretation, but, I can imagine how Microchip would interpret it... (Sorry, I meant to highlight the 8.1 MHz, not the 10%)

 

Not really, specs are clear at 8MHz.  You are hoping to push up to 12MHz, which is well outside where they test/spec oscillator pull.

You may find the next batch of parts shifts on the yield curve.

 

With all this risk, you may be better to choose another micro...

 

I would gladly.  Must be manufacturable on one layer, must be small, can't fit a SOIC.  I am unaware of any options.

 

What about this spec ? :)

 

SOT23-6
• Upto 32 MHz flexible CPU frequency
• 256bytes internal RAM (IRAM)
• 4KB non-volatile flash memory (IROM)
• 5interrupt sources with priority control
• 3external interrupts: INT0, INT1, INT2
• 2set 8/16-bit timers with one capture/compare
• 1set 8/16-bit PWM generators
• 12-bitSAR ADC with 6 external channels
• UARTinterface with SMBus Support
• Widesupply voltage (1.8 V – 5.5 V)
• Wideworking temperature (-40 °C to 85 °C)  

 

SN8F57011DGR

 

I can find price/stock on the SO8 package variant,  SN8F5701SG, 200+ $0.2082, you may need to ask about SOT23-6 price of SN8F57011DGR

 

 

 

 

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

That would be wonderful, except, like so many of these types of processor the actual instruction issue rate is <= 8MHz (Datasheet page 26), so, sure your clock rate might be 32 MHz, but you're never going to get your instruction issues anywhere close to that speed :(.  

 

I think the ATTiny10 really is the absolute fastest you can get an SOT-23-6.

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

CNLohr wrote:
I think the ATTiny10 really is the absolute fastest you can get an SOT-23-6.

 

Then it appears you will have to accept some that will not meet your spec, and account for some % that will not work.

Hope is was not a fixed cost contract!   smiley

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

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

CNLohr wrote:

Must be manufacturable on one layer, must be small, can't fit a SOIC. 

 

QFN packages are manufacturable on one layer, and that opens up a great many more choices than SOT23-6

There are also MSOP10 packages