HAL Timers

I’m struggling to get timers to work, they seem to be very good at locking the Pi solid at random intervals, where am I going wrong?

For example:
1. What happens if either HAL_TimerIRQClear or HAL_IRQClear aren’t called before the next IRQ should trigger? From my tests, it looks like it locks the machine, is that a bug or by design?
2. Can XOS_Hardware be called from IRQ / ABT mode? From the locking I’m seeing, I’m guessing no – SVC32 only.
3. If TimerIRQClear is called when the IRQ hasn’t fired, it locks the machine – is this a bug, or by design?
4. Am I correct in presuming HAL_TimerIRQClear should be called before HAL_IRQClear
5. Am I correct in presuming HAL_TimerIRQStatus hasn’t been implemented?
6. Why on earth are there two IRQClears and why no SWI front to timers to obfuscate the HAL?

The behaviour I’m seeing is that randomly when calling HAL_TimerIRQClear / HAL_IRQClear the machine will just lock solid for no reason.

1. What happens if either HAL_TimerIRQClear or HAL_IRQClear aren’t called before the next IRQ should trigger? From my tests, it looks like it locks the machine, is that a bug or by design?

I’m not sure. On OMAP I know that if you don’t call HAL_IRQClear you’ll stiff the machine (hardware design – the IRQ controller needs to be told to resume processing). But I’m not sure what the situation is on the Pi. But you should certainly make both calls before you re-enable IRQs (or do something which might re-enable IRQs, like calling certain SWIs)

2. Can XOS_Hardware be called from IRQ / ABT mode? From the locking I’m seeing, I’m guessing no – SVC32 only.

It’s safe to call from IRQ and ABT mode. But you do have to remember to preserve R14_svc.

3. If TimerIRQClear is called when the IRQ hasn’t fired, it locks the machine – is this a bug, or by design?

Bug.

4. Am I correct in presuming HAL_TimerIRQClear should be called before HAL_IRQClear

Correct.

5. Am I correct in presuming HAL_TimerIRQStatus hasn’t been implemented?

Correct. However since the timers in the Pi use distinct IRQs, using HAL_IRQStatus should suffice.

6. Why on earth are there two IRQClears and why no SWI front to timers to obfuscate the HAL?

There are two IRQClears because there are (potentially) two distinct hardware units at work. The timer (or USB controller, or video controller, or whatever) can have its own IRQ status register which will need clearing. And then the IRQ controller can also have a register that needs poking (e.g. to make the controller resume processing, as on OMAP).

It might have made for a better design if the IRQ source was responsible for propagating the clear event up the device chain (i.e. make HAL_TimerIRQClear automatically call HAL_IRQClear), but hindsight is always 20:20.

As for the lack of SWI frontends, that’s probably because we’re too busy doing other stuff. There has been some discussion about what a possible SWI interface would look like (and I think part of that discussion is missing as myself and Ben also talked about it over email), but so far nobody’s had a go at implementing something. Feel free to volunteer!

I’ve now dropped using timers as they’re just too unreliable, when using them I was seeing random machine locks, crashes and stack corruption. I suspect there might be more bugs beyond the TimerIRQClear one listed above.

Steve suggested coding the timers into the blitter, which you’d also previous suggested as the method used in ArcEm. So, although I wasted a whole week trying to get Timers to work, after an hour of recoding I did at least get James Pond running natively on the Pi.