RTC Timer not moving

The system time on my embedded SC520 system is not being updated.
The rtc command can read and write to the hardware clock, but QNX never sees
any ‘ticks’ of the system clock, hence anything that uses timers, delays etc
is not working. The system boots using an IPL an Loader based on the sample
non-bios SC400 code. What I think is needed in here is some kind of
interrupt hook into a timer to update the system clock. I can’t find any
info on how I can update the OS’ clock. Any ideas/suggestions most welcome.
Thanks,
Jamie

“Jamie Bannister” <Controlstar@btinternet.com> wrote in
news:a5dfmc$3ee$1@inn.qnx.com:

The system time on my embedded SC520 system is not being updated.
The rtc command can read and write to the hardware clock, but QNX never
sees any ‘ticks’ of the system clock, hence anything that uses timers,
delays etc is not working. The system boots using an IPL an Loader
based on the sample non-bios SC400 code. What I think is needed in
here is some kind of interrupt hook into a timer to update the system
clock. I can’t find any info on how I can update the OS’ clock. Any
ideas/suggestions most welcome. Thanks,
Jamie

If Neutrino never sees any “ticks” from the hwclock, would QNX run at all?
If your timer isn’t free running (ie. requires reload), then you’ll need to
customize your startup code, and override the init_qtime() function with
your own.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Jamie Bannister <Controlstar@btinternet.com> wrote:
: The system time on my embedded SC520 system is not being updated.
: The rtc command can read and write to the hardware clock, but QNX never sees
: any ‘ticks’ of the system clock, hence anything that uses timers, delays etc
: is not working. The system boots using an IPL an Loader based on the sample
: non-bios SC400 code. What I think is needed in here is some kind of
: interrupt hook into a timer to update the system clock. I can’t find any
: info on how I can update the OS’ clock. Any ideas/suggestions most welcome.
: Thanks,

: Jamie


Jamie,

Do you have the embedded kit for X86? In the startup lib for
X86, the function “init_qtime” sets up the timer chip. While
not listed in the code, the default is to use interrupt 0. If
your hardware is setup differently you can add a “qtime->intr=x”
where x is the interrupt wired to your timer chip. This code
also assumes an 8254 compatible timer chip. Again, if your timer
chip is different you’ll need to write the appropriate callouts
(default callout is “callout_timer_8254.S”.

By the way, what startup are you using? The standard “startup-bios”
should work on this board (don’t let the name fool you, it will
work on boards without a bios).


John

\

John


John Wall
QSSL
Custom Engineering Group (R&D)

See below…
“John Wall” <jwall@qnx.com> wrote in message
news:a5gamq$jqm$1@nntp.qnx.com

Jamie Bannister <> Controlstar@btinternet.com> > wrote:
: The system time on my embedded SC520 system is not being updated.
: The rtc command can read and write to the hardware clock, but QNX never
sees
: any ‘ticks’ of the system clock, hence anything that uses timers, delays
etc
: is not working. The system boots using an IPL an Loader based on the
sample
: non-bios SC400 code. What I think is needed in here is some kind of
: interrupt hook into a timer to update the system clock. I can’t find
any
: info on how I can update the OS’ clock. Any ideas/suggestions most
welcome.
: Thanks,

: Jamie

Jamie,

Do you have the embedded kit for X86? In the startup lib for
X86, the function “init_qtime” sets up the timer chip. While
not listed in the code, the default is to use interrupt 0. If
your hardware is setup differently you can add a “qtime->intr=x”
where x is the interrupt wired to your timer chip. This code
also assumes an 8254 compatible timer chip. Again, if your timer
chip is different you’ll need to write the appropriate callouts
(default callout is “callout_timer_8254.S”.

That’s got it. For some reason the timer has been allocated to interrupt 1.
Now everything is ticking along nicely.

By the way, what startup are you using? The standard “startup-bios”
should work on this board (don’t let the name fool you, it will
work on boards without a bios).

I’m using a modified version of the code for startup-explr2, for the 386EX
Intel Explr2, since it appears closest to the AMD SC520. I might go back
and have another look at startup-bios, then. There could be something
useful in there

Cheers for the advice.

Jamie Bannister
Controlstar Systems Ltd


John Wall
QSSL
Custom Engineering Group (R&D)

“Adam Mallory” <amallory@qnx.com> wrote in message
news:Xns91C15ABBFFEF3amalloryqnxcom@209.226.137.4

“Jamie Bannister” <> Controlstar@btinternet.com> > wrote in
news:a5dfmc$3ee$> 1@inn.qnx.com> :

The system time on my embedded SC520 system is not being updated.
The rtc command can read and write to the hardware clock, but QNX never
sees any ‘ticks’ of the system clock, hence anything that uses timers,
delays etc is not working. The system boots using an IPL an Loader
based on the sample non-bios SC400 code. What I think is needed in
here is some kind of interrupt hook into a timer to update the system
clock. I can’t find any info on how I can update the OS’ clock. Any
ideas/suggestions most welcome. Thanks,
Jamie

If Neutrino never sees any “ticks” from the hwclock, would QNX run at all?
If your timer isn’t free running (ie. requires reload), then you’ll need
to
customize your startup code, and override the init_qtime() function with
your own.
It seems that the basic parts that I had been using so far, eg devc-ser8250,

must have worked entirely from their corresponding external interrupts.
Nothing had needed the process manager to come in and preempt them. This
probably explains why the system appeared to lock up at certain points in my
application code (eg an infinite loop that never relinquished control, and
so would never be scheduled out except by a hardware interrupt). Anyway,
I’ve now got the problem fixed (see next post).
Thanks,
Jamie


Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net