OS_Claim (0x1F)

I’m trying to program a function in RISC OS which executes whenever it gets an interrupt (0×02). The problem is that I don’t know how exactly OS_Claim works. Do I have to modify the CPSR as if I was working with a handler, or does it just jump from the IRQ handler to my code and returns to the IRQ handler? I’d also like to show a message via SWI and I dont know if that will be possible from this function.

Thanks.

Have you read the interrupt handling section of PRM 1? Use of the IRQV has been deprecated for a long time and in any case it only receives unknown IRQ’s. Unknown IRQ’s are disabled by default.

Hi Colin,
Well I didn’t know that, but I enable those interrupts after all.
My main problem has to do with the OS_Claim, is the CPSR in IRQ mode?
Here’s my code:

.global _start
_start:
@ enable interrrupts
mrs r0, cpsr
bic r0, r0, #0×80
msr cspr, r0

@ Enable OS_Claim for Interrupts
mov r0, #0×02
adr r1, handler
mov r2, #0

@ Enable Enable_IRQ_1
mov r1, #1
lsl r1, r1, #1
ldr r2, =0×2000B000
ldr r0, [r2, #0×210]
orr r0, r0, r1
str r0, [r2, #0×210]

@ Load value to Compare Register
ldr r2, =0×20003000
ldrd r0, r1, [r2,#4]
add r0, r0, #0xFF00000
str r0, [r2,#0×10]

@ Infinite Loop to check Timer’s Behavior.
loop: b loop

MOV R8, #0
SWI 0×11

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
handler:
stmfd r13!, {r0-r3, r12, lr}

@ disable interrupts
mrs r0, cpsr
orr r0, r0, #80
msr cpsr, r0

adr r0, text
SWI 0×02

text: .asciz “Handler\n”
.align 2

@ Remove interrupt from Status Register
ldr r0, =0×20003000
ldr r1, [r0]
bic r1, r1, #0×2
str r1, [r0]

@ Re-Load Compare Register
ldr r2, =0×20003000
ldrd r0, r1, [r2,#4]
add r0, r0, #0xFF00000
str r0, [r2,#0×10]

@ enable interrupts
mrs r0, cpsr
bic r0, r0, #80
msr cspr, r0

ldmfd r13!, {r0-r3, r12, lr}
subs r15, r14, #4

My main problem has to do with the OS_Claim, is the CPSR in IRQ mode?

You could dump the PSR to someplace and examine the flags to see what the processor mode is?

Or, better yet, look at the PRM. p1-77 states that IrqV is always executed in IRQ mode.

As Colin said, using OS_Claim/IrqV is deprecated. It was used in Arthur (back in, what was it, 1986?) but it is no longer to be used within RISC OS. So you should not be using it.

Look at OS_ClaimDeviceVector (PRM 1-123). Better still, read the chapter on dealing with interrupts.

adr r0, text
SWI 0×02

text: .asciz “Handler\n”

Is it safe to call OS_Write0 in this way? Data is written to the usual output streams, and from IRQ code may not necessarily be re-entrant. Take a look at DADebug.

Oh, and you should always be calling X-version SWIs in IRQ code.

@ Re-Load Compare Register
ldr r2, =0×20003000
ldrd r0, r1, [r2,#4]
add r0, r0, #0xFF00000
str r0, [r2,#0×10]

It’s my own personal style, but I’d be using defined constants there. After a bit of digging, I now know that 0×20003000 is the Pi’s BCM2835 System Timer; loading doubleword from +4 is the 64 bit value of the system timer counter. Writing to +&10 is writing to the System Timer Compare 1. Writing CLO (R0) to to C1 will schedule an interrupt. You already know this, I’m just working through the code.

Something like:

  ; Re-Load Compare Register
  LDR     R2, =(IO_Base + Timer_Base)
  LDRD    R0, R1, [R2, #ST_CLO]  ; only using R0, is LDR*D* necessary?
  ADD     R0, R0, #0xFF00000     ; what is this, about 4 seconds?
  STR     R0, [R2,#ST_C1]

One thing I did notice . . . are those addresses correct? They are indeed the physical addresses of the devices, however are these maintained through the MMU and the logical addressing known within the RISC OS realm?

Hi Rick, Thank you very much for your answer.

To write that code I’ve reading this link http://xinu.mscs.mu.edu/BCM2835_System_Timer and the BCM2835.
The address of the code refers to the System Timer and the IRQ Enabler.
In order to check the Handler I’ve been using OS_CallAVector (SWI 0×34) and in that case PSR is in ‘Monitor Mode’ (this should be different in a real interrupt I think).

What do you mean with this sentence: “Oh, and you should always be calling X-version SWIs in IRQ code” Can I use SWIs in the IRQ Handler?

I’ve seen that both of you have talked about PRM, what is it exactly?

You can find an online version on this site under “Documents”
Here’s another (more complete?) version:

http://www.riscos.com/support/developers/prm/

In order to check the Handler I’ve been using OS_CallAVector (SWI 0×34)

!!!! Please read https://www.riscosopen.org/wiki/documentation/show/IrqV and note the bit that says “It must not be called with OS_CallAVector.”

and in that case PSR is in ‘Monitor Mode’ (this should be different in a real interrupt I think).

What do you mean by Monitor Mode?
One of the following, surely: ABT32, FIQ32, IRQ32, SVC32, SYS32, UND32, or USR32.

What do you mean with this sentence: “Oh, and you should always be calling X-version SWIs in IRQ code” Can I use SWIs in the IRQ Handler?

Please do not think I am being impolite . . . but you are using a deprecated function, calling it incorrectly, and you do not seem to be aware of the two different ways in which SWIs can be called (what the X bit is for; XOS_Write0 vs OS_Write0).
May I suggest that you download a copy of PRM volume one, and read… well, pretty much the first half (you can skip the sprite/text/vdu/input parts for now; and anything to do with IOC, MEMC, and old-style RISC OS).
Pay particular attention to “An introduction to SWIs 1-23” and “Interrupts and handling them 1-119”.

curious:

cspr?

CPSR sorry.
Thank you all, I’ll read that manual and I’ll try to solve the problem.

Hi all!
After reading the PRM for a couple of days, I decided to try the HAL timer API: https://www.riscosopen.org/wiki/documentation/show/HAL%20timer%20API

My idea is to first program using HAL and finally, manually. I’ve followed all the steps that are specified in the webpage, and I’ve seen that some of the HALs work but other ones (I think) are not implemented (HAL_TimerIRQStatus).
To avoid the use of SWIs and make it easier, I implemented a counter that just increments by one each time a timer interrupt occurs. However, this counter doesn’t change. I can’t find a solution to this problem :S

.global _start
_start:

.align 2
counter: .word 0

@ Enable interrupts
SWI 0×13

@ ClaimDeviceVector
mov r0, #5
adr r1, Timer
mov r2, #0
SWI 0×4B

@ IRQEnable
mov r0, #3
mov r8, #0
mov r9, #1
SWI 0×7A

@ TimerSetPeriod
mov r0, #1
mov r1, #0×01000000
mov r8, #0
mov r9, #16
SWI 0×7A

@ Infinite loop
loop:
b loop

mov r8, #0
SWI 0×11

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Timer:

STMFD r13!, {r0-r3, r12, r14}

@ IRQStatus
mov r0, #3
mov r8, #0
mov r9, #5
SWI 0×7A

@ If IRQStatus returns 0, Timer was not the cause of the IRQ.
mov r1, #0
cmp r0, r1
beq out

@ TimerIRQClear
mov r0, #1
mov r8, #0
mov r9, #113
SWI 0×7A

@ IRQClear
mov r0, #3
mov r8, #0
mov r9, #3
SWI 0×7A

@ Counter+1
ldr r0, =counter
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]

out:
LDMFD r13!, {r0-r3,r12,r14}
mov r15, r14

I imagine I will have to change to Supervisor mode to use SWIs but not sure:
MRS R0, CPSR
ORR R0, R0, #3
MSR CPSR_c, R0

SWI 0×13
SWI 0×4B
SWI 0×7A
(etc)

Does your assembler not allow you to use definitions so these (and the “magic values”) can be properly named?

For using the timers – perhaps the HALTimer module would be simpler → http://homepage.ntlworld.com/rik.griffin/haltimer.html

Hi Rick
I can’t execute, for example, bl hal_irq_enable, that’s why I do it myself.
I’ve been able to change the timer period (and see the changes), for example. Is it system timer or timer?
I saw that code when I was looking for information some days ago, but I don’t understand some constants so I’ve tried to do something as simple as possible.
My main aim is to increment a counter when I enter in the handler, but definitely I think it doesn’t execute it.

I saw that code when I was looking for information some days ago, but I don’t understand some constants so I’ve tried to do something as simple as possible.

The first thing to do, then, is to decrypt the code.

.global _start
_start:

.align 2
counter: .word 0

@ Enable interrupts
SWI "OS_IntOn"

@ ClaimDeviceVector
mov r0, #5       ; IOC Timer 1
adr r1, Timer    ; pointer to handler
mov r2, #0       ; value to pass in R12 (should be module workspace pointer?!?)
SWI "OS_ClaimDeviceVector"

@ IRQEnable
mov r0, #3       ; Enable IRQs for device #3
mov r8, #0       ; Call HAL routine
mov r9, #1       ; HAL_IRQEnable
SWI "OS_Hardware"

@ TimerSetPeriod
mov r0, #1       ; Timer #1
mov r1, #0×01000000 ; Timer period
mov r8, #0       ; Call HAL routine
mov r9, #16      ; HAL_TimerSetPeriod
SWI "OS_Hardware"

@ Infinite loop
loop:
b loop

mov r8, #0       ; R8 not relevant to OS_Exit
SWI "OS_Exit"    ; how do we come here anyway?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Timer:

STMFD r13!, {r0-r3, r12, r14}

@ IRQStatus
mov r0, #3       ; Device #3
mov r8, #0       ; Call HAL routine
mov r9, #5       ; HAL_IRQStatus
SWI "OS_Hardware"

@ If IRQStatus returns 0, Timer was not the cause of the IRQ.
mov r1, #0
cmp r0, r1       ; why not just "CMP R0, #0" ?
beq out

@ TimerIRQClear
mov r0, #1       ; Timer #1
mov r8, #0       ; Call HAL routine
mov r9, #113     ; HAL_TimerIRQClear
SWI "OS_Hardware"

@ IRQClear
mov r0, #3       ; Clear IRQs for device #3
mov r8, #0       ; Call HAL routine
mov r9, #3       ; HAL_IRQClear
SWI "OS_Hardware"

@ Counter+1
ldr r0, =counter ; An ADR might work here...
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]

out:
LDMFD r13!, {r0-r3,r12,r14}
mov r15, r14

You are running this as a module or single-tasking, aren’t you? TaskWindows are bad…

but definitely I think it doesn’t execute it.

In this case, if it was me, I’d drop in a call to transmit a ‘.’ on the serial port and then watch (on another computer connected to the serial) to see if anything is received. You could also spit out ABCD (etc), a letter for each state that the code is passing through to see how much (if anything) actually gets executed.

Hi!
I’ve tried to try with Timer 0 rather than Timer 1.
In this case, the OS freezes when I run the program.
Is there any condition I’m not considering in my handler?
thanks for your support.

https://www.riscosopen.org/forum/forums/5/topics/2207?page=2#posts-27672

Some questions:

Why .align 2 ?

Which memory space is counter defined in?
Which memory space in the IRQ looking for counter
Which memory space are you looking in to check if counter has changed.

Do you know the purpose of stacking registers on the way into the IRQ? What about R8 R9?

Hey Dominic,
I thought I didn’t have to define any memory space.
‘Counter’ is located in a specific address which is passed to the handler to operate with it.
Respect to align 2, I always start my codes with that directive, in this case it’s not necessary.

Depends on how you are doing it. Most likely they are in different memory spaces. If you can provide detailed answers you may understand what is wrong. In you code snippet you don’t provide enough info for us to work it out. Eg how you start your code.

@Dominic: Can you define what you mean by ‘memory space’ please?

Dominic:

Why .align 2 ?

It’s a crappy weird assembler which specifies its alignment as a power of two instead of bytes. Thus, 2^2 is a four byte word.

Which memory space is counter defined in?
Which memory space in the IRQ looking for counter
Which memory space are you looking in to check if counter has changed.

Martin – I am wondering if he isn’t asking what I asked a while back – are we working with logical or physical addresses here?

Do you know the purpose of stacking registers on the way into the IRQ? What about R8 R9?

Evidently not.
Taking a brief look at the device driver interrupt details in the PRM (1-128), it says that registers R0-R3 and R12 may be corrupted (RISC OS source indicates R11 can also be corrupted but don’t rely upon this). And, as you noticed, R8 and R9 are trashed. Looking at the code, it looks as if R9 is temporarily used in the IRQ handler (stacked/unstacked around use); so using R8 and R9 (not banked in IRQ mode) will be trashing whatever these may have been previously. This will be unexpected (for example APCS requires the v# registers to be preserved).

Adrian:

I saw that code when I was looking for information some days ago, but I don’t understand some constants so I’ve tried to do something as simple as possible.

Could you please link to the place where you saw this code, and a (complete) copy of what you are trying to get working? Looking at your code, it is not clear how or when it runs. Module? Application? Multitasking?

I am going to go out on a limb and wonder if you are not running this in a TaskWindow (based upon the infinite loop – nobody would do such a thing if they also wanted to check to see what effect the code is having). If this is the case, you do realise that any time your task is paged out (which will be, statistically, the majority of the time), your pointers given to OS_ClaimDeviceVector will point at random parts of other applications. If you want to do it like this, you’ll want to claim a little bit of RMA and place your interrupt handler in there (as a stop-gap until you write a proper module).

Also, investigate the HALTimer module – because due to hardware differences, what works on a Pi may not work on a Beagle, or Panda, or…
(plus, there’s no need to reinvent the wheel)

Hi! Well, I use gcc downloaded (from the PackMan), and using the Risc Os’ ‘cmd’ I compile them using ‘as’ and link them with ‘ld’.
I just want to create a loop and each time I receive an interrupt I print something on the screen.

Main:
.section .init
.globl _start
_start:

.align 2
counter: .word 0
text: .asciz “works\n”
.align 2

@ Enable interrupts
SWI “OS_IntOn”

@ ClaimDeviceVector
mov r0, #6 ; IOC Timer 1 or Device identifier provided by HAL_TimerDevice???
adr r1, Timer ; pointer to handler
adr r2, counter ;
SWI “OS_ClaimDeviceVector”

@ IRQEnable
mov r0, #3 ; Enable IRQs for device #3
mov r8, #0 ; Call HAL routine
mov r9, #1 ; HAL_IRQEnable
SWI “OS_Hardware”

@ TimerSetPeriod
mov r0, #1 ; Timer #1
mov r1, #0×01000000 ; Timer period
mov r8, #0 ; Call HAL routine
mov r9, #16 ; HAL_TimerSetPeriod
SWI “OS_Hardware”

@ Infinite loop
loop:
@ Load counter to see if it has changed
adr r0, counter
ldr r0, [r0]
cmp r0, #0

@ If it’s different from 0, it has entered the handler
beq jump
adr r0, text
SWI 0×02

@ If it’s 0, just do the loop again
jump:
b loop

mov r8, #0
SWI “OS_Exit”

Handler:

.timerhandler
STMFD r13!, {r0-r3, r12, r14}

; HAL_TimerIRQClear
; Clear the timer IRQ
MOV R0, #1 ; Timer1
MOV R8, #0
MOV R9, #113
SWI “OS_Hardware”

; HAL_IRQClear
; Clear IRQ
LDR R0, #3
MOV R8, #0
MOV R9, #3
SWI “OS_Hardware”

; Disable Interrupts in general
SWI “OS_IntOff”

; enumerate_list ??

; Increment Counter
ldr r0, =counter
ldr r1, [r0]
add r1, r1, #1
str r1, [r0]

; Enable Interrupts in general
SWI “OS_IntOn”

; Reload registers
LDMFD r13!, {r0-r3,r12,PC}

Do I have to change to Supervisor mode to call SWI?
Rik uses http://www.squeakysoftware.org/haltimer.html ‘enumerate_list’ and other code that I don’t understand.

Hi, thanks. If I have time I’ll convert that to objasm format and see what it does.

Next question – how are you running the program?

By the way:

You are still trashing R8 and R9. At this stage of development, be paranoid and stack every register you touch. It’s the safest approach. Also keep your comments up to date with the code : ; restore the mode flags we saved in r4 followed by a read from R6 indicates something is wrong… ;-)

If I have time I’ll convert that to objasm format and see what it does.

Interesting exercise.
What’s the assembler?

What’s the assembler?

Judging by the ‘@’ comments and the weird syntax, I think it might be “gas” or whatever the gcc assembler is called.

Judging by the ‘@’ comments and the weird syntax, I think it might be “gas” or whatever the gcc assembler is called.

ah, Ben’s “favourite” (not)