Search

Technical Discussion Group Forum

This forum is provided for user discussion. While Beacon EmbeddedWorks support staff and engineers participate, Beacon EmbeddedWorks does not guarantee the accuracy of all information within in the Technical Discussion Group (TDG).

The "Articles" forums provide brief Articles written by Beacon EmbeddedWorks engineers that address the most frequently asked technical questions.

To receive email notifications when updates are posted for a Beacon EmbeddedWorks product download, please subscribe to the TDG Forum of interest.

TDG Forum

PrevPrev Go to previous topic
NextNext Go to next topic
Last Post 22 Mar 2004 11:00 AM by  elf-coastal@buici.com
Calibrating the TIMER source constants
 2 Replies
Sort:
You are not authorized to post a reply.
Author Messages
elf-coastal@buici.com
New Member
New Member
Posts:


--
18 Mar 2004 12:01 PM
    This is the thread so far.
    ====================
    One of the problems that I've identified is that the essential system timer,
    AKA jiffy timer, doesn't run at the expected rate. With the primitive tools
    that I have on hand, I've come up with a circumstantial explanation.

    Two of the LH7A400 timers can run at either ~2kHz or ~508kHz. The
    documentation states that the 2kHz timer is has an exact cycle frequency of 1.9994 kHz. This would mean that there would be about 1999 counts every second. Using the 1Hz RTC which appears to be reasonably accurate, I've measured 1993 and 1994 counts each second which approximates a frequency of 1.994 kHz.

    For the task at hand, counting either 19 or 20 times per jiffy is too
    inaccurate. Calibrating the 508kHz counter source is a little more
    difficult, so I haven't yet done it. It should provide a more accurate time
    base, but it doesn't. So, I suspect it is because the published time
    constants are not accurate.

    So, here's the question. Is the published 2kHz timer constant incorrect, or
    is it just variable? If it is wrong, what are the others? 508kHz ~= 508.469
    kHz 3.7 MHz ~= 3.6864 Mhz Who accurate are these numbers?

    ====================
    Hi Marc,

    I have a few additional questions...

    - B2 silicon on the A400 did have an issue with a noisy RTC that gave
    inaccurate 1sec tics. Can you check if your board (KEV or SDK?) has B3
    silicon?

    - depending on how you write the code to check the 1 sec interval to ount
    pulses, you could have some uncertainty. The RTC has a 1msec delay before the interupt is generated (see UG) and the interrupt latency also applies. The timers themselves have an uncertainty of upto 1 clock before they start incrementing. Does your timing test run once or over several seconds?

    - Timer1's output can toggle a pin (TBUZ) on the A400 - if you connect a
    frequency counter or scope, you can measure the period much more accurately.

    I'll try and do the measurement myself later today, but you can test in on
    your own board as well just to confirm there isn't something wrong with the
    circuitry.

    ====================

    The CPU has these markings:

    SHARP
    LH7A400-N0B-000
    0309 Korea
    101810B3

    Is this a B3 part?

    - depending on how you write the code to check the 1 sec interval to ount
    pulses, you could have some uncertainty. The RTC has a 1msec delay before the interupt is generated (see UG) and the interrupt latency also applies. The timers themselves have an uncertainty of upto 1 clock before they start incrementing. Does your timing test run once or over several seconds?


    I don't think that these latencies should be a problem because of how I perform the computation. Here's how it works. I initialize the RTC to interrupt every second. I do this by loading the clock with zero and setting the match for one. On every interrupt, I reset the clock value to zero. I was skeptical that this would be correct, but it keeps pace with my wall-clock. Then, I set one of the timers to run free. On every RTC interrupt I read the timer value and compare it with the last read value. In this case, interrupt latencies should be cancelled as long as they are reasonably consistent.

    The thing I'm not certain about is the correctness of my one second interrupt from the RTC. The discrepency of 4 or 5 counts is about 2ms which could be due to an error in my RTC setup. However, I would expect that a 2ms slew would be noticeable when compared to wall-clock time over a period of a minute.

    A frequency counter is not one of my tools on-hand. That would be a logical place to look if I had one.

    Let me explain how I got here in the first place.

    I'm trying to get a 100Hz timer interrupt. By all accounts, the 2kHz timer source is not precise enough. At best, it will be about 0.3% too fast when I use a load count of 20. I observed that the 2kHz source wasn't precise enough because the time would drift relative to wall-clock time. The trouble was that switching to the 508kHz source wasn't noticably better.

    Help me understand this. If I set the load value to 1 and the frequency source to 2kHz, how close to a 500.15us period should I get?
    elf-coastal@buici.com
    New Member
    New Member
    Posts:


    --
    18 Mar 2004 12:47 PM
    This is really a Sharp issue and not a Logic issue.
    elf-coastal@buici.com
    New Member
    New Member
    Posts:


    --
    22 Mar 2004 11:00 AM
    The Sharp documentation for the LH7a400 states that the 2kHz timer frequency is 1.9994 kHz. It turns out that it is really 1.994kHz.
    You are not authorized to post a reply.