Jittering clock output on Tiny13 - going INSANE (internal RC

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

Well, I just don't know where to turn, so I've come here again :)

I've got an ATTiny13 running at 9.6MHz (internal oscillator) running the following code;

while(1) { PORTB ^= (1<<PB1); }

And I get a noticable jittering on the output of about ~1.0% of the duty [yes, I did ammend this - my scope can only give me a 2% graduation grid and I can watch the jittering between two graduation marks, most times it's half a mark, sometimes it'll jump a full mark ].

I've decoupled the heck out of the DC input, the output is only connected to my scope (I even tried decoupling that but to no difference), the input power is clean, 5V regulator being powered from a 7.4V lipo input source.

I've got the tiny13 reset pulled up to 5V with a 10K resistor and I even tried a 1K resistor.

It's decoupled with a 22uF 10V tant + 4.7uF 10V tant + 0.1uF ceramic + 1uF ceramic.

Is it normal for the AVR internal clocks to be this bad? Am I missing something amazingly simple?

Anyone else even suffered this?

Regards,
paul. :(

Last Edited: Wed. Mar 12, 2008 - 11:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should point out that even if I change clock divider (eg, DIV8) or if I slow down the switching (by putting a busy-wait loop) the jitter still persists.

I've checked the scope too, it doesn't jitter on other sources.

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

The Tiny13 can toggle an output pin by writing a one directly to the PIN register. In your case you just write a one to PINB1 and the output state will toggle.

BTW, did you remember to disable interrupts? Any interrupt activity will cause jitter.

ATtiny13 Date Sheet wrote:
Toggling the Pin Writing a logic one to PINxn toggles the value of PORTxn, independent on the value of DDRxn. Note that the SBI instruction can be used to toggle one single bit in a port.
You would have to look at your compiler output assembly to see if the optimizer does this or not with PORTB ^= (1<<PB1);.

Last Edited: Fri. Mar 7, 2008 - 06:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike, so, PORTB = (1<<PB1) ? thanks for that trick :D

Yes, interrupts are disabled too (was one of my first thoughts as well) :(

I'm trying to put together a crystal clock source so I can try that, though the Tiny13 doesn't directly support an Xtal.

I can appreciate that the RC osc would deviate +/-200ppm over time but within 1mS seems a bit too strange at this point (and it's more like 1000ppm).

Paul.

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

Bad batch of AVR's ?

I just replaced the tiny13 with one I received about 20 minutes ago (another lot of 100) and what do you know... it's rock steady now.

Trouble is I tried at least 2 others from the same (previous) batch - wonder if there was a problem, or if I somehow just magically stuffed up something somewhere both times.

Paul.

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

Are you sure PB1 was set as an output. Maybe you were just picking up local noise on the scope? Not that I expect this to be the case, you just posed a stumper and I have to make some kind of guess :).

I couldn't find any errata that appears to apply and your Vcc is more than high enough for 9.6 MHz. Maybe try bumping the OSCCAL value by one just for fun. It seems appropriate seeing as how 'magic' appears to be involved here :). Double check all the fuse settings? Make a sacrifice to the new AVRtv RoboOdin?

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

Mike,

Certainly seems like one of those "Will we ever know?" situations. I've still got the AVRs on my bench after having been removed from the boards (all SMD stuff).

I was going to try fiddle with the OSCCAL values but I couldn't find a method of setting them (tried using avrdude but it told me that the 'calibration' byte was read-only).

As for the PB1 output etc, yes, it was set. I actually tried PB0,1,2 and 3 to be sure.

I've got a couple of other units being returned to me all suffering the same 'jittering' symptoms, so it's going to be interesting to see if replacing the AVR on the boards produces a fix in each case.

Paul.

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

The ATMEL application note page has at least two notes/programs for RC oscillator calibration.

http://www.atmel.com/dyn/product...

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

Quote:
Mike, so, PORTB = (1<<PB1) ?

No,

PINB = (1<<PB1)

/Martin.

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

Thanks Martin.

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

This is a known characteristic of the internal RC oscillators.

I am sorry that I cannot provide a reference right now. My internet service is too slow to connect to that particular server today(elm-chan.org, where I recall seeing the jitter reported along with waveform photos). But for now, please take my word for it. This is what you get with an AVR on-chip RC oscillator.

The on-chip Rc oscillators are find for clocking the microcontrollers, but I would not rely on the on-chip clock for any application that required spectral purity or a high degree of pulse width stability.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

Farang,

I found a couple of sites which showed up those jitter images. It's interesting to see the original/earlier clocks were far more stable than the newer ones.

It's a bit of a problem - basically I want an AVR solution for my application which needs to be physically small and moderately low cost (I could move to tiny25's assuming they had a decent clock - though who knows).

Absolute spectral purity isn't needed but the jittering experienced is rather bad all things considered.

Anyone know if it's for EMI/RF regulations or just cheap and nasty production (eg, cost cutting)?

At least I now know the source of the problem - I'll simply have to go through all my tiny13's and select the ones with the lower jitter ranges for the tasks that need it, for other things that aren't jitter sensitive I'll just use the jittery ones :(

Overall, yes, I'm pretty disgusted - I didn't expect amazing stability from the internal RC oscillator but at the same time I wasn't anticipating it to be -this- bad. What's worse is that it seems rather common across a spread of the AVR's, not just the 'cheaper' ones.

:?

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

Quote:

It's interesting to see the original/earlier clocks were far more stable than the newer ones.

Quote:

Anyone know if it's for EMI/RF regulations ...

I don't "know", but there were some threads a while back that discussed that possibility.

I'd ask Atmel. Sounds like a legitimate pre-design-in question to me.

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

Some of us go out of our way to make the clock jitter for lower EMI. I've used a spread-spectrum oscillator on a few designs. It's kinda like cheating. The EMI isn't any lower but the way they take the measurement they only look at peaks. So no one peak is over the spec. Of course if they would just increase the span it would all get integrated together and it would be way out of spec. But hey, they make the rules!

Go electric!
Happy electric car owner / builder

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

The thing that throws me off thinking that it's EMI/RF regulations bypass tricks is that the amount of jitter varies considerably between the chips. You'd think if it was EMI/RF issues then it'd be fairly constant across a batch of chips.

Does anyone actually know how the OSSCAL value adjusts the RC oscillator? I mean technically - eg, does it still run the RC at 'full speed' and then periodically absorb/pull a pulse, or does it adjust a n-bit resistor network which in turn adjusts the RC time constant? Personally I'm biased to thinking it's the resistor network method - though I have just written an email off to Atmel to ask them about this issue, possible fixes and also how the OSCCAL setup works electronically.

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

sgomes,

I've noticed a few Class-D amplifier chips doing the spread-spectrum trick to get EMI clearance, you're right, still the same collective amount of EMI, just spread around a bit. Wonder how long before that rule gets ammended.

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

I'll be interested in hearing Atmel's comments on the topic. Considering that the entire oscillator is on-chip, this jitter is not surprising. I worked on a couple of ASICs that had on-chip phase locked loops that locked to external sources, and jitter was a major concern - particularly crosstalk within the chip. 3% to 5% actually sounds pretty good to me compared to some of our experienced with PLLs.

Look for some controllers (maybe not from Atmel) in the future to incorporate MEMS resonators on the chip to give stability equal to or better than quartz. It is noted that your need is now.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

A support ticket/request has been made to Atmel and confirmed now - so I guess it's just a case of waiting.

While I can appreciate that there's going to be a level of crosstalk, the fact that it varies by a magnitude between chip batches (that I've received, though they both seem to carry the same markings on the underside of the chip) makes me concerned.

... for now, I'll have to wait :\

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

Just ran a batch of 10 AVR tiny13's here and 60% of them have excessive jitter. The remaining 40% still jitter but on a 'sufficiently minimal' level.

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

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

Yes, I actually came across those images/sites - was rather similar to what I'm experiencing :(

I really hope there's a fuse/tweak fix for this. If not, there's going to be a lot of money I'm going to have to burn :(

What's sad is that the problem naturally didn't show up in the initial prototypes or the initial production... only now once things have been put into full production has the problem manifested... good ole murphy's law!

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

Swept through a large range of OSCCAL values to no noticable effect.

Pulled any and every spare line either high or low via a 10K resistor and made sure I had pullups enabled as well, there was some /marginal/ improvement but still not sufficient to clear it for production.

Right now I'm thinking I'll try move to a tiny25 chip since it has the same pinouts (effectively) as the tiny13, if the tiny25 can prove to be more stable (different clock engine) then I'll just have to accept the extra expense, at least I'll have a working product again :(

(Thus far still no response from Atmel)

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

I've used a Tiny13 once to try and see how small i could really go in making a microcontroller spit out a monochrome video signal.

Turned out the internal 9.6MHz clock showed up as a very visible jitter of, i would say, some 3~5%. My tv could not get a fixed HSYNC signal to sync to. I quickly discontinued testing after that, since the Tiny13 does not allow a crystal or resonator, but requires a full oscillator, which in turn would be bigger than the uC itself. Kinda beat the point as far as my test was concerned. Using an external clock did however stabilise the signal.

I'm guessing the jitter is a result of noise present in the on-chip RC oscillator.

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

Which package? The DFN, properly laid out should be quieter than the little dip as you have the back side of the chip to a good ground. Why two tantalums? Is there another load? Schematic please? I would also look at changing the 0.1 to 0.01, though that shouldn't make a lot of difference.

"It's easier to ask forgiveness than it is to get permission" - Admiral "Amazing" Grace Hopper.

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

Microsurfer, I'll add in a 0.01 as well, no problem there.

I'm using the SOIC8 chips.

Will try a tiny45 today to see if there's a noticable improvement, if so, I'll just shift production over to use the 25's potentially (I don't have any 25's on hand).

EddyB,

I suspect it's coming down to the problem that we developed/tested/ran-first-batch on the "older" tiny's... but along with the new batch of units we also picked up a newer batch of tiny's. I can easily imagine that you'd not get a proper HSYNC :(

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

Switched over to a tiny45 today to compare - jittering is substantially reduced relative to the 13. I will sample another half dozen or so to see how things go.

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

I had been burnt by relying on unspecified parameters in the past (a long time before AVRs came along).If you are making a product to sell, and its important that you be able to make these in the future or repair units in the field, you might find it best to obtain specifications from Atmel before going ahead.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

Farang,

I agree, it would be nice to get some clarification on the spec. Given that the devices are sub-$20 USD units there's not a lot of wiggle room for field-service options, usually I just have clients return the units for reflashing/updating/chip-replacements, the postage service tends to make more profit from it than anyone else :(

I agree that it's a bad idea to rely on a parameter that's specifically unspecified. My as yet unanswered ticket with Atmel does inquire regarding that detail.

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

inflex wrote:

I've got an ATTiny13 running at 9.6MHz (internal oscillator) running the following code;

while(1) { PORTB ^= (1<<PB1); }

And I get a noticable jittering on the output of about 2~5% of the duty.

There must be something wrong on your program, but not on the AVR.

I have never seen such a tremendous big jitter of 5% on all my ATtiny13.

I assume, your original code contain several interrupt handlers, which cause jitter.
Disable all interrupts to see the real jitter.

Please post a complete (compileable) code including output port initialization.

Also be sure, that it was compiled with optimization level -Os and for the right target.

Also enable the internal pullup on all unused IOs and only the test pin as output, but no other.
This prevent, that floating pins or shorted pins may influence the AVR.

Peter

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

Peter,

My mistype or something there - that's actually supposed to be ~1.0% (see first post - ammended).

As mentioned in previous posts, I have no interrupts going, I ended up whittling the code down to nothing but one active like, essentially the square-wave output.

As a precaution I decoupled with a lot of caps in many magnitudes (eg, 22uF, 4.7uF, 1uF, 0.1uF and now 0.01uF), the supply is a lipoly battery via a 5V LDO/LN regulator (1A rated and heatsinked, also with its own decoupling on both sides as per mfg spec for the regulator device).

Initially I too also thought it had to be the software, it sent me insane, eventually even when I've reduced it down to this one active line of code I'm still getting the jittering.

What's more annoying is that previous batches of tiny13's have worked without problem and it seems too that current batches of tiny45's also work fine without appreciable jitter (there is some but it's below the level of being a problem).

Hope you can provide some insight.

/** Main program **/

#define F_CPU 9600000UL

#include 
#include 
#include 

#define SOUTP PB0
#define SINP PB3

int main(void) {

//  PB0: Servo output pulse pin
//  PB1: Alternative servo output, no active connection
//  PB2: Switch mode selector, pulled up to Vcc via 10K 
//  PB3: Servo input pulse, connected to receiver
//  PB4/ADC2:  Pot voltage reading, 10K

   DDRB |= (1<<SOUTP);  // servo output pulse on SOUTP
   PORTB |= (1<<PB1); // enable pullups on unused pin(s)

   /** ADC setup **/
   ADCSRA =  (1<<ADEN)|(1<<ADPS1)|(1<<ADPS0);
   ADMUX = (1<<MUX1); // ADC2

   cli();  // No interrupts please.

   while (1) { PORTB ^= (1<<SOUTP); } // test pattern

}

Compiled using avr-gcc

avr-gcc -Wall -mmcu=attiny13 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just received a response from Atmel - I'm actually quite shocked as it did not address the points raised in the original question and the ticket was marked 'closed', so I guess I don't get to have a response?

I've submitted a follow up ticket specifically asking for an actual specification/number for the anticipated jitter from the RC clock.

If nothing else they could reply to say that "We do not have that figure available, sorry".

Maybe I'm going about this all the wrong way but I'm certainly starting to feel dismayed.

:-(

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

Same software, same board - different chip.

500K FLV video of each device on the scope

Tiny45:
http://www.pldaniels.com/flying/...

Tiny13:
http://www.pldaniels.com/flying/...

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

So the summary is that the Tiny45 series, or at least the model and sample that you have, does NOT have the jitter on the internal oscillator that IS exhibited by the Tiny13 and others? [Slow computer, slowish connection, old eyes--a little hard to tell on the video. ;) ]

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,

Summary is correct :) Video is of relatively poor quality, perhaps I'll do a 720x576 version tomorrow with a decent DV cam rather than the grain attempts of the Digital-camera, but yes, you got it in a nut-shell.

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

My request on the per-cycle jitter specification has been passed up to the Atmel engineers, hope to hear some news on matters in the next few days or a week.

Paul.

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

I've not yet heard back from Atmel engineers about a 'spec' for the jitter, however I've changed over to using the tiny25's and I'm pleased to report that the jitter is completely under control now such that I can return to production again (at a slightly higher cost).

For now, the tiny13's will still be used but for things that aren't going to be sensitive to jitter variations.

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

I am a little bit disappointed that Atmel hasn't responded yet. Maybe they are not aware that this was holding up production.

Its good to hear that the ATTINY25 solved your problem, even though it was at an increased cost.

If Atmel ever does bless you with a spec, or even a constructive comment, please share it with us.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

Farang,

I most certainly will be reporting back when I get some news.

I did inform Atmel that it was causing a production halt until such time as it was resolved, though I think that perhaps that wasn't forwarded onto the actual engineers as a request.

Perhaps they (Atmel) plan to retire the tiny13 in the near future anyhow since the tiny25 performs everything the 13 does as well as supporting xtals directly and has a second timer. That said, although the cost difference is only about 21c/unit (75c vs 98c) it certainly does add up even on small commercial runs (100's of units).

Paul.

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

UPDATE

Finally got a reply from Atmel (thankyou).

Quote:

The IC designers tell us that jittering is difficult to measure in production, so it is
not logged. Some tinys, in specific Tiny44 has been characterized in lab for
jitter, and I think it is fair to say that the jitter at 8 MHz clock is
on 1 - 1.5 ns range. While the 8 MHz period is 125 ns, this represents
roughly 1% jitter. We do not have characterization information on Tiny13 or Tiny25.

There is not much that can be done to this currently in the existing
MCUs. Older AVRs, like the Tiny26 has different rc osc topology, which is
much more stable, but that topology is several times larger in die area,
and consumes also maybe 10x the power if the current rc osc. Hence, the
choice has been for the current one, despite of the shortcoming with jitter.

So at least now we know where thing stand.

Thanks once again to the Atmel support for coming forward with this information.

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

Quote:
Thanks once again to the Atmel support for coming forward with this information.
And you for letting us know.

I think we need a sticky for things likje these. It's not an unpublished error, but yet something to be aware of.
Hmm, a title change for that existing sticky ... is that an option ?

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

Nard,

No idea how to make anything here sticky or do such things to the threads.

I would assume someone in a 'higher position' would be able to take the quoted information perhaps and put it into a sticky thread?

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

Thank you for filling us in. 1% doesn't sound like much, but when it occurs in video, its an eyeful. Also, as they say, jitter is difficult to specify - peak or RMS, over what part of the spectrum, etc.

That is took Atmel over two weeks to respond is regrettable.

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

In our situation, anything over 0.5% generally manifests as murmering/jittering on the servos (higher quality servos generally respond to lower jitter %'s).

For now, we'll work with the tiny25's which at least with this latest batch seem to be overall better with their stability than the tiny13's. For the future we'll have to start investigating perhaps using the tiny24/44 (24 is more than ample), at least with their 16 bit counter it makes some of our coding a lot simpler though we'll have to redo the boards, software and tooling - oh well, who said life was easy ;)

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

Right! If it was easy, anybody could do it...

--
"Why am I so soft in the middle when the rest of my life is so hard?"
-Paul Simon

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

inflex, sorry ... had to make dinner, but I already asked the moderator (Jörg) to have a look at this. We need to remember this !

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

> That is took Atmel over two weeks to respond is regrettable.

In particular if you consider that the Norwegians have a long
traditional vacation period around Easter. ;-)

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Thanks Jörg, for the tweak ;)

inflex, ... GO AHEAD !

Nard

A GIF is worth a thousend words   They are called Rosa, Sylvia, Tessa and Tina, You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

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

OK, I slightly changed the title of that sticky thread, and added a
posting with a pointer to the Atmel explanation inflex posted above.
I hope that's fine with everyone.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Suits me - hope this saves a few people a couple of weeks of sanity.