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 a USART, and transmitting "Hello World" in a loop, shows up some of the problems with the complexities associated with the fuse and SFR settings that are now required on some devices.

For very, very accurate frequency checks, a scope of 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.