• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 30 subscribers
  • Views 606 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Correcting Time Drift on TM4C1294NCPDT with HIBRTCT

Scott Kassan
Prodigy 195 points
Other Parts Discussed in Thread: TM4C1294NCPDT

I'm having issues with the RTC drifting on my TM4C1294NCPDT project. I've read about the trim register and am trying to use that for correction.

My idea is to interrupt using the RTC match register once per second. Then using Timestamp_get32(), calculate the number of system clock ticks that have transpired since the last RTC second tick. This should match the frequency that I'm driving the main clock with. If it's different, adjustments to the HIBRTCT register can be made to adjust the RTC rate accordingly.

My problem is that no matter what value I place in the HIBRTCT register, I always get roughly 120004000 ticks between RTC interrupts. (The system clock is running at 120 MHz.) My understanding is that the RTC and the system clock are running on two different oscillators, but my experiments would seem to indicate otherwise. I've double checked that the system clock is configured to run from OSC0 and OSC1 (16 MHz) and the RTC is configured to run from XOSC0 and XOSC1 (32.768 kHz). I've also confirmed that the OSCDRV is set correctly for the circuit on this project.

Is my theory valid? Can I use the system clock to adjust the RTC? Are there any other methods of calculating a value for HIBRTCT to correct for clock drift? (The system is not connected to a network, so no authoritative time source is available.)

Below is the temporary code I'm currently using for the HIB interrupt for my testing:

static Bits32 delta = 0xFFFFFFFF;
extern Swi_Handle clockDriftSwi;
Void HIBHwiFxn(UArg a0)
{
  static Bits32 lastStamp = 0xFFFFFFFF;
  Bits32 currentStamp = Timestamp_get32();
  delta = currentStamp - lastStamp;
  lastStamp = currentStamp;

  Swi_post(clockDriftSwi);
  HibernateIntClear(HIBERNATE_INT_RTC_MATCH_0);
}

Void clockDriftSwiFxn(UArg unused1, UArg unused2)
{
  System_printf("%ld\n", delta);
  delta = 0xFFFFFFFF;
}

  • 0
    TI__Guru**** 244400 points
    Hello Scott,

    If the code is progressing in a predictable order, then wouldn't that be the case. If you add a delay before the read of the number of system clocks then does it show a different value?

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 195 points

    Amit,
    No, I don't think so. The HIBHwiFxn is interrupt driven off of the RTC match interrupt every second. That's being driven by the XOSC. So if I deliberately set the trim value to something like 0x8005, I would expect that the number of system clock ticks between RTC seconds would be different than 120000000, because if the trim is working as expected, that would slow down or speed up the RTC, but the system clock is still spinning along at 120 MHz.

  • 0 in reply to Scott Kassan
    TI__Guru**** 244400 points
    Hello Scott,

    The hibernate trim is applied once in 64 seconds for the RTC Mode and not every second. The data sheet section on RTC Trim mentions the same. So being able to do it every second is not a viable option.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 195 points
    Amit,
    Yes, I realize that. (Though it would be every 60 seconds. I'm running the RTC in calendar mode.) So my calculations and adjustment would only take place every 60 seconds. But my understanding is that the trim is essentially used as the clock divider. So once the trim is applied, I was expecting it to remain in effect until it was adjusted again. Am I interpreting that incorrectly. Is it the case the it is applied as a clock divider only every 60 seconds, and for the other 59 seconds the nominal divider of 0x7FFF is used? I guess I can make my "diff" variable an array and store 60 or 120 of them and see if any of those diff values change. I'll report my results.
  • 0 in reply to Scott Kassan
    TI__Guru**** 244400 points
    Hello Scott,

    No trim does not work as a clock divider. It works as a counter adder or subtractor to adjust the clock count.

    Regards
    Amit
  • 0 in reply to Scott Kassan
    Prodigy 195 points
    Amit,
    Indeed, I was misinterpreting the data sheet. With the trim set to 0x8005, most deltas between interrupts are about 4000 ticks above expected. But every 60 seconds, there's a delta that's about 26000 ticks above expected. So as you suggested, the trim is only applied ever 60th second. It doesn't apply from that point forward. Given this information, I think I can proceed to test my automatic clock adjustments.