IOC Timer / IRQs

Neil Coffey

unread,

Jul 18, 1997, 3:00:00 AM7/18/97

to

I am attempting to use IOC Timer 1 from within a relocatable
module, and wish to attach an IRQ routine to be called whenever
the counter value reaches 0. My understanding of what I need
to do is as follows:

1) Set the latch values as necessary and enable the timer.
For example:

MOV R2, #&3200000
MOV R0, #high_value
STRB R0, [R2, #&54]
MOV R0, #low_value
STRB R0, [R2, #&50]
STRB R0, [R2, #&58] ; Start timer

2) Set bit 6 (IOC Timer 1 bit) of the IRQ mask. Code I have
for this is as follows, though I suspect it may not be
correct:

MOV R0, PC
ORR R1, R0, #&0C000000
TEQP R1, #0 ; This line is given on PRM page 1-134
; Is it correct?
LDRB R1, [R2, #&18]
ORR R1, R1, #1<<6
STRB R1, [R2, #&18]
TEQP R0, #3
MOV R0, R0

3) Attach the routine to device 6:

MOV R0, #6
ADR R1, counter_routine
MOV R2, R12
SWI "OS_ClaimDeviceVector"

I'd be grateful if somebody who knows more about these things than
I do could confirm that the above is correct or amend it as
necessary, as it doesn't appear to work. As I say, I suspect the
code in (2), which causes an address exception.

Thanks in advance,

Neil

--
Neil Coffey
Student in French/linguistics, Oxford University
http://ox.compsoc.org.uk/~neil/

Paul Clifford

unread,

Jul 18, 1997, 3:00:00 AM7/18/97

to

In article <ant18123...@st-annes.ox.ac.uk>,
neil....@st-annes.ox.ac.uk (Neil Coffey) wrote:

> I'd be grateful if somebody who knows more about these things than I
> do could confirm that the above is correct or amend it as necessary,
> as it doesn't appear to work. As I say, I suspect the code in (2),
> which causes an address exception.

The following snippet, based on the timing code in GBoyEm, should
work. The only real difference, apart from OS_EnterOS (my code was
called from user mode), is that you used TEQP R0, #3 in part 2 of your
code instead of TEQP R0, #0, although I've no idea what effect, if
any, that would have.

OS_DeviceIOCTimer1 * 6
IOC_registers * &3200000
IRQ_clear * &14
IRQ_mask_a * &18
t1_latch_low * &50
t1_latch_high * &54
t1_go_command * &58
disable_IRQs * 1 << 26
disable_FIQs * 1 << 27

[claim the timer]

mov r0, #OS_DeviceIOCTimer1
adr r1, counter_routine
mov r2, r12
swi OS_ClaimDeviceVector

mov r3, pc
swi OS_EnterOS
mov r0, #IOC_registers
ldr r2, counter_speed ; 16 bit number
strb r2, [r0, #t1_latch_low]
mov r2, r2, lsr #8
strb r2, [r0, #t1_latch_high]
strb r0, [r0, #t1_go_command]
mov r1, pc
orr r2, r1, #disable_IRQs + disable_FIQs
teqp r2, #0
mov r0, r0
ldrb r2, [r0, #IRQ_mask_a]
orr r2, r2, #1 << OS_DeviceIOCTimer1
strb r2, [r0, #IRQ_mask_a]
teqp r3, #0
mov r0, r0

[release the timer]

mov r3, pc
swi OS_EnterOS
mov r0, #IOC_registers
mov r1, pc
orr r2, r1, #disable_IRQs + disable_FIQs
teqp r2, #0
mov r0, r0
ldrb r2, [r0, #IRQ_mask_a]
bic r2, r2, #1 << OS_DeviceIOCTimer1
strb r2, [r0, #IRQ_mask_a]
teqp r3, #0
mov r0, r0

mov r0, #OS_DeviceIOCTimer1
adr r1, counter_routine
mov r2, r12
swi OS_ReleaseDeviceVector

--
He who shouts loudest can only hear his own voice. Those with true
knowledge listen to those with true faith. And those with closed ears
never hear the swing of the reaper's blade.
- The Book of Cataclysm.

Neil Coffey

unread,

Jul 18, 1997, 3:00:00 AM7/18/97

to

In article <19970718....@plasma.demon.co.uk>, Paul Clifford
<mailto:pa...@plasma.demon.co.uk> wrote:

> The following snippet, based on the timing code in GBoyEm, should
> work. The only real difference, apart from OS_EnterOS (my code was
> called from user mode), is that you used TEQP R0, #3 in part 2 of your
> code instead of TEQP R0, #0, although I've no idea what effect, if
> any, that would have.

Aha, this does indeed solve the problem that I was experiencing.
Thanks.

I now have another problem! The call to OS_ClaimDeviceVector now
causes the machine to hang (but not lock up completely). I *assume*
that what is happening is that the IRQ handler is being called
and not returning properly. The machine is thus left with IRQs
disabled but FIQs enabled (for example, the pointer still moves,
but Ctrl + Break has no effect).

According to the PRMs, the device routine must return with
MOV PC, R14 having cleared the device's interrupt condition.
So, my question is: given that the device in question is IOC timer
one, do I need to "clear its interrupt condition"? If so, how
do I do this? (One idea that occurred to me was to wait for
1/2000000 of a second, but I haven't actually tried this, don't know
if it's the right answer.) And if not, how *do* I return
from the routine? For example, if the routine consists simply
of the single instruction MOV PC, R14 the machine still hangs in
the way I have described.

So once again, I'm appealing to anybody who may know about
these things to help me out... Thanks in advance,

Ralph Barrat

unread,

Jul 18, 1997, 3:00:00 AM7/18/97

to

In article <ant18123...@st-annes.ox.ac.uk>, Neil Coffey
<neil....@st-annes.ox.ac.uk> writes

>I am attempting to use IOC Timer 1 from within a relocatable
>module, and wish to attach an IRQ routine to be called whenever
>the counter value reaches 0. My understanding of what I need
>to do is as follows:

>>snip

>Thanks in advance,
>
>Neil
>

Not sure what is wrong (although enabling the interrupt before setting
the handler is not a good idea????). I do the same thing with the
following code (written years ago, but still works OK on SA RPC) :

.setup_timer1
STMFD (sp)!,{R0-R11,link}
;
MOV R2,#&3200000
;
;set up handler address first
MOV R0,#&06;IOC timer 1
ADR R1,timer1_handler;
MOV R2,R12;R12 val to be passed
SWI "OS_ClaimDeviceVector"
;
;enable timer interrupt
MOV R2,#&3200000
LDRB R1,[R2,#irqclearA]; = &14
ORR R1,R1,#&40;timer 1 bit
STRB R1,[R2,#irqclearA]; = &14
;
LDMFD (sp)!,{R0-R11,pc}

Comments may not be 100% correct, because I just added some of them.
Code was written a long time ago, and seems to work.

Ralph Barrett

Change the 'Z' into an 'F' to send a reply. Its a Scottish Island.

Paul Clifford

unread,

Jul 19, 1997, 3:00:00 AM7/19/97

to

In article <ant18225...@st-annes.ox.ac.uk>,
neil....@st-annes.ox.ac.uk (Neil Coffey) wrote:

> According to the PRMs, the device routine must return with
> MOV PC, R14 having cleared the device's interrupt condition.
> So, my question is: given that the device in question is IOC timer
> one, do I need to "clear its interrupt condition"? If so, how
> do I do this?

Using the constants defined in my previous example:

timer_code
mov r3, #IOC_registers
mov r0, #1 << OS_DeviceIOCTimer1
strb r0, [r3, #IRQ_clear]
; decrement your counter or whatever
mov pc, r14

--
"The universe runs on the complex interweaving of three elements:
energy, matter, and enlightened self-interest."

Neil Coffey

unread,

Jul 19, 1997, 3:00:00 AM7/19/97

to

In article <19970719....@plasma.demon.co.uk>, Paul Clifford
<mailto:pa...@plasma.demon.co.uk> wrote:

> > So, my question is: given that the device in question is IOC timer
> > one, do I need to "clear its interrupt condition"? If so, how
> > do I do this?
>
> Using the constants defined in my previous example:

Thanks. The problem is now solved.