RTC utility

Hi,

Iam using “rtc hw” command to update the Software clock from the Hardware real time clock.

I’m doing an rtc test as below.

Getting the time T1 from the Hw clock.
Delay(2000)
Getting the time T2 from the Hw clock.

but the difference(T2 - T1) seems to be more than 6(ideally should be 2) sometimes, when powering up after a long time in OFF state.

Can someone help me with this? Also at the failure instant the Delay function expires in 29 ms instead of 2s.

Regards
-sheran

Two things to keep in mind.

  1. The delay(1000) call is only ± .5(timer interval). I don’t know what your timer interval is set to. There is a default, but you might have changed it.

  2. delay() stops your thread for at least 1000 ms, I think it is supposed to side conservative. So if given a choice between 999.5 ms and 1000.5 ms, it will go with 1000.5. But there is no guarantee that your thread will start immediately. If something else of a higher (or equal) priority is running, you may not run right away. Having more than one core reduces but does not eliminate this possiblity.

I’m not able to make out exactly wut is happening.

ideally the difference between the rtc samples should be 2s(and may be a tolerence of +/-1s). it is more than 6s, also 13s at sometimes.

and at the same time Delay(2000) exits around 30ms(calculated using rdtsc). Delay function returns 0, indicating there is no premature termination in delay().

The obervation is as below during fault condition.
Delay()(in ms) Sampl2 - Sample1(in s)
21.624601 9.461287
25.635117 8.094097
29.677696 6.941538
32.55788 6.32764
35.255726 5.737802

Using the rtc command to update the software clock can cause the update to take place over a period of time. In other words it may not instantly change the time in the software clock.

Take a look at the -r rate option in the doc’s for rtc.

Tim

Thanks for your input. I’m analysing in that focus. There is less documentation in the QNX site for the “-r rate” option. can u give me more info on that?

when i used the command as “rtc -r 10000 hw”, no failure was observed. i need to do more trials.

what impact will this change have? on the system clock.

-Sheran

Sheran,

Here’s all you need to know.

qnx.com/developers/docs/6.3. … r/rtc.html

You probably want a 1 instead of 10000.

Tim

Thanks for the input. I’m able to understand better the usage of rate option.

I have a query,
How does the system clock(i.e. CLOCK_REALTIME ) caculate the current time and date when the device is kept in OFF state for considerable amount of time and then booted up?

Note:
“rtc hw” is not added in the start up script, to synchronise the System clock with the hw RTC.

Regards
Sheran

Their are two different clocks involved. There is a battery backed up clock that runs all the time whether the cpu is powered on or not. This clock is usually read at boot time with the rtc program. rtc then sets the system clock. The system clock is just a data variable that is incremented whenever the timer interrupt occurs.

To conclude the source of the system clock is the battery back-uped hardware RTC.

but i removed the “rtc hw” command from the start-up script. But still the the system clock seemed to have the expected values across power-cycles.

Regards
Sheran

Then you are not looking carefully enough, :slight_smile:.

OK, i will check once again tomorrow. May be there can be a rtc sync in the Boot scripts. I removed it only from the application startup scripts.

But My observation was as below:

  1. Stop Watch → 5s, System Clock - 5s
  2. Power Off Immediately.
  3. Wait for 12hrs
  4. Power ON.
  5. Stop Watch → 43200s, System Clock → 43165s
  6. Stop Watch → 43260s, System Clock → 43225s, executed “rtc hw”.
  7. Stop Watch → 43560s, System Clock → 43560s

I was responding to your previous statement that after rebooting without running rtc, that the time was correct. I’m not talking about the rate the clock is going at, I’m talking about the actual time. It’s not possible for this to be the case without having run rtc or entering the system time manually.