Pi- HALTimer does not seem to call the timer handler

On my 512Mb RPi and at least one other example, the HALTimer module does not seem to function correctly.

Symptom:
The handler code passed to the system as part of setting up a timer does not appear to be called.

Tests done so far:
Using the zip file from Rik Griffin’s site and running his Test program shows a list of ‘0’ results rather than the expected increasing values of the tick counter.
Modifying the Test program to attempt to verify if anything is working by changing the timer interval from 5 & -4 to 5 & -20 correctly fails the setup SWI.

This code used to work very well on an Iyonix with RISC OS 5.whatever-was-there-in-2005. I do not have the source and cannot find it on the site pointed to by at least one message from rik.

The problem with HALTimer v0.04 (01 Mar 2007) is caused by using fixed IRQ numbers (those from Iyonix) which will not work with Beagle/Panda/RPi.
If you patch the module so that the branch at offset 0×0B40 (BGE …) is not executed (I have changed it to a “BGT …”) then it will do the right thing
i.e. it asks the IRQ number by calling HAL_TimerDevice routine.
I have just done this patch on my Pandaboard and now interrupts are active.

Hmm, interesting idea Willi but unfortunately on my Pi it produces a hard lock-up that requires a poet cycle (a poet cycle? Damn You Autocorrect! a power cycle. though maybe a poet would be more useful? “A reset button by any other name would sound as beep”?)

So far as I can tell from my copy of the module it doesn’t include a reference to HAL_TimerDevice, so that’s puzzling. Do you by any chance have a copy of the source for the module? I know RIk used to keep it publicly accessible but sadly http://www.btinternet.com/~rik.griffin/ is not there any more. Even the Wayback machine can’t find it!

Haven’t you tried http://squeakysoftware.org/ ?

Rik is about! If he hasn’t spotted this thread by then I’ll email him when I’m back at work, where I have an up to date email address.

Haven’t you tried http://squeakysoftware.org/ ?

I thought Tim was after the source. Mind you the web pages do say that the contact address is in the help files so an email contact is possible.

I have indeed tried squeaky software (from where I got the v0.04 version, without sources) and emailing rik at his denbidge account. Nuttin’ so far..

The haltimer.zip currently downloadable from http://squeakysoftware.org/haltimer.html does have the source code inside.

I heard from Rik and he kindly sent a revised version to test; more on that when I get a chance.

It looks like he’s updated his ZIP too – the source is now included so at least I can stare at code instead of StrongEd disassembler text.

Sorry, I’ve been on holiday! :)

I’m working with Tim to resolve this. The reason the HALTimer module used fixed IRQ numbers is that the hal_timer_device call was broken on an early version of RO5.

Once we get this fixed I’ll put the latest version with source on the web site at http://www.squeakysoftware.org/

The fault appears to be in the IRQ handler code in HALTimer – but I can’t work out what’s wrong.

As I understand it, pre RO5, the procedure is:

OS_ClaimDeviceVector to claim the IRQ
IRQ handler clears interupt and returns to address in R14.

In RO5 there’s a choice: if bit 31 of R0 is set in the call to OS_ClaimDeviceVector, unclaimed IRQs are passed on to earlier claimants (for shared PCI IRQs).

A RO5 IRQ handler has a choice of claiming the IRQ by returning with LDMFD r13!,{pc} or passing it along with MOV pc,r14 (ie returning to the address on the stack, or in r14 respectively).

In this instance I’m claiming the IRQ for Timer 1, which on the Iyonix is IRQ 42 and on the RPi is IRQ 3. This isn’t a shared IRQ (is it?) – so am I correct in saying I should not set r0 bit 31 when calling OS_ClaimDeviceVector, and my IRQ handler should return with MOV pc,r14 ? In other words, the procedure will be the same for RO4 and RO5?

Using a minimal IRQ handler which just clears the IRQ and increments a counter:

STMFD r13!,{r0-r6,r14}

; first clear the IRQ
MOV r0,r12
BL  hal_irq_clear  ; corrupts r0-r3,r14

LDR  r0,Counter
ADD  r0,r0,#1
STR  r0,Counter

LDMFD r13!,{r0-r6,pc}

Counter DCD 0

This stiffs the Pi when called but works on the Iyonix.

Any ideas please?

I think the problem you’ve run into is that the Pi requires you to use HAL_TimerIRQClear to clear timer interrupts. This is different to previous RISC OS 5 machines which had the timer clear logic bolted on to HAL_IRQClear. Just remember to heed the warning on the wiki that you need to call both HAL_TimerIRQClear and HAL_IRQClear (some machines will require only one, and some may require both)

the Pi requires you to use HAL_TimerIRQClear to clear timer interrupts

I didn’t clock the significance of that new entry point when it went passed on CVS, I thought it was Kernel private, but in effect has it changed the public HAL API too?

Wouldn’t it be simpler to special case it in the HAL_IRQClear in the Pi’s HAL? If the entry point is required because there’s something special about the timer on the Pi, then that’s exactly what the hardware abstraction layer is for – to hide the caller from subtle platform differences.

has it changed the public HAL API too?

Yes. The timer & IRQ APIs are pretty much the only two that are public.

Wouldn’t it be simpler to special case it in the HAL_IRQClear in the Pi’s HAL?

Simpler yes, neater no. I never liked the way the Tungsten & OMAP HALs had to special-case the timer IRQs inside HAL_IRQClear. And neither did Castle, judging by the “FFS – get this sorted” comment in the Tungsten HAL.

Is it the case then, that the correct procedure for handling a timer IRQ on any current hardware, is to call both HAL_IRQClear and HAL_TimerIRQClear if that entry point exists?

Thanks for the help here :)

Yes. Call HAL_TimerIRQClear with the timer number, then HAL_IRQClear with the IRQ number.

Just out of interest, is the order important?

Yes. When an IRQ occurs, some IRQ controllers (e.g. OMAP) latch the IRQ source and need to be given a manual kick to restart processing once the IRQ has been dealt with. So if you called HAL_IRQClear before calling HAL_TimerIRQClear then the IRQ controller would see that the timer is still generating an interrupt and immediately latch that result and keep the ARM’s IRQ line raised. This would then cause your IRQ handler to be run again, resulting in two interrupts per timer tick instead of one.

Tim reports that HALTimer seems to be OK on the Pi now, I’ll test it some more myself as well, then make the new version available at www.squeakysoftware.org. Thanks for the help Jeffrey :)

Yup; the latest version seems to be good to go. I’ve been beating it up all day with no problems except that Rik’s Test BASIC program locks up everything when run within a StrongEd task window. Now that one really mystifies me…
But for my needs in Squeak it is just dandy.

The test program is extremely crude – it installs its HALTimer callback handler in application space. So if the program is paged out when a timer IRQ occurs, badness ensues.

Would be useful to know what the solution was – how to get the correct IRQ number from the Timer device on Rasperry Pi, which timer to use, etc. It appears that squeakysoftware.org hasn’t yet been updated with the fixes for Raspberry Pi. I’m working on a hardware project and need a timer IRQ every microsecond or every four microseconds, depending on how I implement the GPIO pin twiddling.

Sorry for the delay, my web page has now been updated.

The source code is on there so feel free to poke around and see how it’s implemented.

The confusion about finding the correct IRQ was only because an old version of RO5 had a bug in the HAL_TimerDevice code, and I had done a nasty hack to make HALTimer work on that version.