MCU effective clock frequency check

[Wimax]

Hello Everybody 

Perhaps this is a trivial question, but what method do you consider the simplest and, possibly, sufficiently accurate to understand whether the microcontroller you are using is actually  operating at the clock frequency you declare at the beginning of your programme (within known tolerances ), after setting a significant number of registers more or less protected by unlocking sequences, start-up switching modes and so on ?

[trastikata]

Toggling a LED with 1s period is the simplest way that I am using. If you meant that you need to check the actual clock offset then you'd need an oscilloscope.

[top204]

I always setup USART1 for a particular Baud rate, and transmit "Hello World" using HRsoutLn, in a loop, with a small delay between transmissions.

If it is received correctly, the frequency that the compiler has been told to compile for, is the speed the device is actually running at.

[Wimax]

Yes, my question is more of a survey. I often use the timed toggling of a pin, but actually the UART is demanding in terms of frequency tolerance, usually +- 2.5% per side, and in practice it narrows as the frequency increases.
Probably a test with a fairly high baud rate (say 115.2 kbaud or more) leaves no room for doubt.

[trastikata]

usually +- 2.5% per side, and in practice it narrows as the frequency increases.

The relative accuracy remains the same 2.5% is always 2.5%

Using the internal oscillator or an external crystal, if you have main frequency correct i.e. 4 or 8 or 12 ... MHz verified by a blinking LED, then the minor frequency offset should be within the desired tolerances for 99% of the applications. For the remaining 1% you'd need an oscilloscope anyway.

[Wimax]

Yes, the theoretical relative error is independent of the baud rate, but the higher the frequency, the more precise the clock must be for that percentage to remain valid.

[trastikata]

You are right.

[kcsl]

I always use the flashing LED indicator, especially when using a PIC I'm not familiar with. My thinking is that just by looking at the LED flash rate, you can get an immediate indication if the PIC is actually running, and depending on the actual flash rate compared with what you're expecting, gives you a clue if you've got configuration issues around the clock source, dividers, PLL etc.

Joe

[Stephen Moss]

The problem with a flashing an LED at 1 second is the lack of accuracy, it could easily look like a second but be 10% out as how accurate it is determined by the observers perception of time and expectation that it will be 1 second.

If you need accuracy then I would think a timer interrupt toggling a port pin in the ISR which is then measured with an oscilloscope, logic analyser or Timer counter and comparing that to the expected frequency of the full timer count would be more accurate, that is how I would do it. 

[JonW]

I use a couple of methods. If the MCU has a clock out on a pin, then I will enable that; if not, I will use 115200 baud from the UART. If I am in the Lab, then I sometimes use a speccy to sniff off the clock easily. Finally and most often, I use a timer interrupt and toggle a pin. Most of my code is structured around a fast-timed interrupt-driven loop as a base clock anyway, so I can easily produce multiple timed events, so toggling a pin on the interrupt flag set is quite normal for me.

[top204]

A scope or frequency meter is the ideal solution. However, a lot of people do not own one of them, so cannot run those tests.

I have always found a high Baud rate setting on USART1, and transmitting "Hello World" in a loop, shows up some of the problems with the complexities associated with the config fuses and SFR settings that are now required on some devices.

For very, very accurate frequency checks, a scope or frequency meter is a must, as well as a controlled temperature around the crystal, or device, if using the internal oscillator. However, for general checks, you cannot beat the simple USART1 test, and a program such as:

Code Select Expand

Device = 18F27Q84
Declare Xtal = 64

Declare HSerial1_Baud = 115200
Declare HRSOut1_Pin = PORTC.6

Do
    HRsout1Ln "Hello World"
    DelayMs 500
Loop

If a serial terminal receives 'Hello World', without any extraneous characters in, or around it, then the device's config fuses, and/or SFRs have been set appropriately for the frequency required.

My one warning on this, is to never trust a simulator for device frequency settings, as they 'generally' get it very wrong. Always use a "real" device.

[Wimax]

I wonder if the Counter command can also be used, obviously with the possibility of injecting an external signal with a sufficiently high frequency accuracy.
I imagine that once the theoretical clock frequency has been defined in the program, the command performs a loop counting the signal edges for a time window based on the number and theoretical duration of the machine cycles used. Apart from the intrinsic calculation accuracy of the algorithm, if the time window is sufficiently wide in relation to the input signal frequency, any deviation of the actual clock from the theoretical clock should be detectable.

[trastikata]

We are straying from the OP but here's what I do .

- 1 second blinking LED - excellent way to check the fuse and register settings, in 99% of the cases is all what we need.

- if our design assumes the internal oscillator as clock source then we accept its tolerances and temperature offsets.

- if crystal is used then the crystal is precise and stable enough even for 100% of the USB applications, no need to check ppm offsets.

- if higher stability is required, maybe a TCXO - they have high initial absolute accuracy too, why would you verify 1ppm offset with anything else beside specialized equipment.

- in some extreme cases I used the 1pps output from a GPS module as reference clock to correct internal counters.

My point is if such high accuracy is required in an application, then specialized equipment should be available too ... you are not going to assemble a smartphone with a hammer, chisel and nails, right ... well I did one time and the "fix" was permanent

[Wimax]

Just to share a personal experience of a few years ago.
I had a problem with a Pic24 for which I selected an external quartz that, due to an error in the BOM, had been replaced with a version with the same case but with a clock that was nominally about 8% slower (I know...it's a "big" number). Here the problem was at the source, but the substance remains the same.
Everything worked fine in the preliminary tests, apparently even the switching of an LED that was performed in a timer interrupt with a flashing frequency of about 0.5 Hz, which was used to signal the correct operation of the object and also provided an indication of the correct frequency setting.
Problems arose when I had to count a series of pulses for a well-defined time. There was a systematic counting error (which, incidentally, at first glance did not appear to be constant with the frequency), but the frequency of the test source was accurate. The PCB did not have an output for the UART, but I was able to acquire a sufficient number of samples with continuous automatic sampling at a theoretically known speed, saving them on SD so that I could analyse them on the PC. The FFT analysis showed that continuous sampling was performed at a rate lower than the theoretical one, in my case by about 8%. A test via UART would certainly have always failed with standard transfer speeds as all the settings for a 32 MHz MCU would be applied to an actual MCU running at 29.48 MHz.