Clock Speed not consitent

[636steve]

Hi
I have developed a board that outputs a 50/50 pwm at 2.39Khz. This is running an internal clock speed of 20MHz.
The prototype has worked fine but on a production batch of 100 boards I have about 20% reject rate where the output pwm is approx 3.1KHz.

They are all running the same program and the fuse settings are all the same as well.

As the program is the same I am assuming this is the speed of the internal clock is out. Is there a way to correct this?

Thanks

[SpenceKonde]

There's something going on there that doesn't add up. The internal oscillators on these parts are dead on accurate IME, never seen one that was even 1% off it's target under normal conditions. That would be miles out of spec even on a classic AVR, and the oscillator is far better on these parts.

Which part are you using? What method do you use to generate the PWM? What else is the program doing?

To rectify a problem like this you need to first identify what is actually happening and the one thing I'm certain of is that you don't have as clue what's wrong. I don't either, but that's not a surprise, since I can't see your code nor look at your board layout (though I have trouble imagining how you'd manage a 30% timing error through poor PCB design, I also know nothing about your design.). If it was 25% fast or 20% slow, then easy, the OSCCFG fuse is set wrong.

Much more debugging effort is required here, and if you want my thoughts on this, I'd need to see the code and schematic.

[SpenceKonde]

Now, had I already released megaTinyCore 2.4.0, which has code to tune it's internal oscillator on startup to target different speeds, I would be wondering if that feature was selected and was in use when it shouldn't have been, but that hasn't been included in any released version (it's in github version, but not the releases).

[636steve]

Hi

Thanks for the replies. I have done some digging and it would appear it is something to do with my code (no surprise!!). If I load the TCA0Demo4 code into a out of spec board it works at the specified frequency so it would appear the chips are fine.
So, what am I doing wrong? I need to generate a 2.39KHz pwm on pin 13 (PA3) of an attiny214. I believe this is W03. I have included my setup code below. I am not a software guy by trade, and got this going by looking at various examples so please forgive me if there are any stupid mistakes :)

TCA0.SPLIT.CTRLD = TCA_SPLIT_SPLITM_bm;
TCA0.SPLIT.CTRLA = 0; //disable TCA0 and set divider to 1
TCA0.SPLIT.CTRLB = TCA_SPLIT_HCMP0EN_bm; //PWM on WO3
TCA0.SPLIT.HPER = 99; // Count down from only 99
TCA0.SPLIT.HCMP0 = 50; //50% duty cycle
TCA0.SPLIT.CTRLA = TCA_SPLIT_CLKSEL_DIV64_gc | TCA_SPLIT_ENABLE_bm; //enable the timer with prescaler of 64

[SpenceKonde]

that looks reasonable - you actually don't have to enable split mode - the core does that by default (unless you're also overriding the initializatioion functions) overriding init or something.
This does compile with enough space if you've got PB2 free to connect a serial adapter to. that will make debugging this a lot easier. I'm gonna predict that that this code never malfunctiions, and there';s some weirder bug elsewhere in your code resulting in the problem. I imagine the whole thing does more than just output fixed PWM.

void setup() {
  // put your setup code here, to run once:
  // TCA0.SPLIT.CTRLD  = TCA_SPLIT_SPLITM_bm;
  TCA0.SPLIT.CTRLA  = 0; //disable TCA0 and set divider to 1
  TCA0.SPLIT.CTRLB  = TCA_SPLIT_HCMP0EN_bm; //PWM on WO3
  TCA0.SPLIT.HPER   = 99; // Count down from only 99
  TCA0.SPLIT.HCMP0  = 50; //50% duty cycle
  TCA0.SPLIT.CTRLA  = TCA_SPLIT_CLKSEL_DIV64_gc | TCA_SPLIT_ENABLE_bm; //enable the timer with prescaler of 64
  Serial.begin(9600);
  Serial.printHex(TCA0.SPLIT.CTRLA);
  Serial.println();
  Serial.printHex(TCA0.SPLIT.CTRLB);
  Serial.println();
  Serial.printHex(TCA0.SPLIT.CTRLD);
  Serial.println();
  Serial.printHex(TCA0.SPLIT.HPER);
  Serial.println();
  Serial.printHex(TCA0.SPLIT.HCMP0);
  Serial.println();
  Serial.printHex(CLKCTRL.OSC20MCALIBA); 
  Serial.println();
  Serial.printHex(SIGROW.reserved_1[14]); //for fucks sake, the io headers list the location of the cal byte in the sigrow as "reserved"... 
}
void loop() {
  // put your main code here, to run repeatedly
}

[SpenceKonde]

Wait, no.... the code you posted, you said the "bad ones" output 3.125 kHz output did you not? How do figure that was bad?

I would say that the ones outputting 2.31 are malfunctioning. 20,000,000 / 64 = 312,500Hz, so 100 timer ticks per cycle gives 3.125 kHz.

Doublecheck what all the fuses are set to, too. If OSCCFG was set for 16 on a board, you'd expect ~2.5 kHz which isn't too far from what you see....

[636steve]

Hi
I will try your code tomorrow when I get back in front of the boards.
I am outputting the pwm which feeds another circuit via a high value resister and then reads the timing of a 'modified' pwm fed back. There is also 3 leds to indicate different states as well.

I had already checked the fuse settings and they were on 20Mhz. I will double check this tomorrow to make sure.
So it would appear the majority that aren't working are actually working and vice versa.
Thanks for your help.

[SpenceKonde]

When the boards are in front of you?! Real developers debug hardware thile the hardware is behind their back... shrug

So you're timing a moderately high frequency input? How you going about that? My prediction is that there's a bug in how you're approaching that, and so with no input, it is going off in a direction you don't expect.

And what timer are you using for millis, if you have that enabled? (I would imagine TCD0 as all 1-series should be defaulting, so that wouldn't have a notable impact unless you were using that to time the other pin with - and if you're doing THAT, you should also be debugging them with the boards behind you and your hands tied up with the power cable, because you are trying to make life harder for yourself; the TCD is an awful timer for capture...). In that vein though,, if not using millis()., micros(), or delay() in your sketch,, definitely disable millis if you're using a 2k part. Saves couple hundred bytes in many circumstances.

(the TCD is one of the most complicated, uncooperative, and byzantine peripherals found on a mainstream non-xMega AVR [on xmega, every peripheral is complicated and byzantine - the xmega line combines the complex mess that peripherals turn into when engineers are given cheap transistors and nobody holds their leash on usability or usefulness, with the limitations of the AVR instruction set - my theory on why they didn't really take off is that anyone who was prepared to deal with that kind of learning curve would just learn some ARM architecture that's more widely applicable.). The fact that TCD0 is difficult to work with is WHY it is the default timer for millis on parts that have it - the chance of someone wanting to reconfigure it is practically zero, so using it for millis leaves the timers they would be likely to play with available. Even at that, I only use it on megaTinyCore - Dx parts have enough TCB's that I just throw one of those at millis by default; I'll probably support TCD millis over there for the DD-series parts, since they only have 2 TCBs on the 14 and 20 pin devices, and that's not enough to be able to require that either a TCB or the only TCA be used if one wants millis() ; I consider 2 TCBs vs 3 TCBs to be the dividing line between a comfortable number of timers and feeling confined and limited by the number of available timers. Maybe a hypothetical device with 64k+ flash and >40 I/O pins to feel limited by the timers even with 3 TCBs, but I'd have to meditate on that question... if it had a second TCA, I don't think I'd start sweating if I couldn't move millis timekeeping to a TCD.. And a hypothetical 8-pin tiny with 2 TCBs, I think would also feel comfortable. Anything between those extremes, with 3 TCBs you can burn one for millis and feel okay with that because you've still got 2 to play with, and so you can use one before you're in the danger zone, while with only two, if you burn one for millis, using the remaining one is a declaration that you've forseen all eventualities that would force you to to use a TCB, which is a bit intimidating - like trading your car key to some dude along the roadside. However compelling the trade he's offering is, you'd better be real sure the next town is as close by as you think it is, you know?... But I digress - I digressed very very far didn't I?)

[636steve]

Hi, lol yes you digressed very far and I hardly understood a word of it.

I am using the arduino 'pulseIn' command to measure the incoming signal.

What is strange is that boards that were reading 2.39KHz are now reading 3.1KHZ if I re-program them. Changing the 99 value to 130 I can get them all to output approx. 2.39KHz.