Jan Kiszka wrote:
> Detlef Vollmann wrote:
> >>> Now I have another question on this: on the PXA I have a hardware
> >>> problem so that I must sometimes set the next match value to the
> >>> match value after the next one, so effectively loosing one
> >>> interrupt.
> Just out of curiosity: What is the technical background of this issue?
> Does it mean that the hardware is not able to trigger a timer event over
> a certain period of time and you therefore have to defer the event until
> this is possible again? Do you know ahead of time when this will happen?
> Or only when you try to set the timer and the hardware tells you about
> it somehow?
Here's the original comment and code from

    /* Loop until we get ahead of the free running timer.
     * HACK ALERT: it seems that the PXA timer regs aren't updated right
     * away in all cases when a write occurs.  We therefore compare with
     * 8 instead of 0 in the while() condition below to avoid missing a
     * match if OSCR has already reached the next OSMR value.
     * Experience has shown that up to 6 ticks are needed to work around
     * this problem, but let's use 8 to be conservative.  Note that this
     * affect things only when the timer IRQ has been delayed by nearly
     * exactly one tick period which should be a pretty rare event.
    do {
        OSSR = OSSR_M0;  /* Clear match on timer 0 */
        next_match = (OSMR0 += LATCH);
    } while( (signed long)(next_match - OSCR) <= 8 );

> Looks like designing a real-time application around such a quirk isn't
> that easy.
It's not so difficult to work around the problem for a single system.
What's difficult is to find a solution in a framework that wasn't
built with such a problem in mind.

> But it's not a generic PXA issue, is it?
It seems it is...


Detlef Vollmann   vollmann engineering gmbh
Linux and C++ for Embedded Systems    http://www.vollmann.ch/
Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/

Xenomai-core mailing list

Reply via email to