AT91SAM7X SYS IRQ: RL-ARM problems by change from edge to level mode (for RTT etc.)

Maybe the mass of text above hides the answer:

We cannot change to the three other timers (TCx) because we use them already for other pupose.

There are no missed irqs but the scheduler of rl-arm requires triggering of the irq (sys_ctrl_interrupt in RTX_Config.c) for additional runs of the scheduler for queued calls to os functions like isr_xxx from isr's.

But the irq-controller (aic) supports software triggering of irqs only in edge mode, _not_ in (for rtt and others required) level mode.

I my opinion this is a design problem of the scheduler of rl-arm that requires a special workarround.

Please keep sending your ideas. This usually helps!

Maybe the mass of text above hides the answer:

We cannot change to the three other timers (TCx) because we use them already for other pupose.

There are no missed irqs but the scheduler of rl-arm requires triggering of the irq (sys_ctrl_interrupt in RTX_Config.c) for additional runs of the scheduler for queued calls to os functions like isr_xxx from isr's.

But the irq-controller (aic) supports software triggering of irqs only in edge mode, _not_ in (for rtt and others required) level mode.

I my opinion this is a design problem of the scheduler of rl-arm that requires a special workarround.

Please keep sending your ideas. This usually helps!

What I was thinking was: Isn't your problem that the scheduler somehow may miss the sys_ctrl interrupt, resulting in the scheduling stopping.

In that case - is it possible that another interrupt handler that gets activated regularly (possibly from any of the other three timers) may notice that the scheduling have stopped, and may then either reinitialize the sys_ctrl interrupt, or may manually trig a new sys_ctrl interrupt?

The specific thing with an edge-trigged interrupt is that if that edge is missed, it stays permanently missed. But if any other interrupt handler gets trigged and is able to see time, it is possible to detect when a specific interrupt source for some reason no longer gets serviced.

A hung timer interrupt can be seen by too long time passing without the ISR touching a global variable.

A hung UART receive interrupt can be seen by the serial buffer having data available, but no UART_RX interrupt time-stamping a global variable.

A hung 1-second RTC can be seen by an internal timer counting more than 1 second without any RTC interrupt. A hung timer can be seen if enough RTC one-second interrupts happens without the timer ISR timestamping a global variable.

So in most situations, it is possible to write an application that can auto-repair an ISR that isn't running. Of course, such a mechanism is only a second-line repair backup. The first-line goal is to figure out why an ISR is no longer trigged, and see if there is a firmware bug that may be fixed. But now and then, chip manufacturers happens to release hardware that just can't be 100% trusted, in which case a "software watchdog" to supervise the problematic interrupt source is the only available route.

You're saying you use all other timer. Fine - if the desired interrupt rate is a multiple of one another (say, the first timer interrupts every 10[ms], the second every 20[ms]), you can handle these in the same ISR. freeing one timer.

The other timers (TCx) are not used for continous intervals but for external monitoring and gating (via TIOA) and run not continously (only on demand but often). So I cannot use them as a clock to divide etc.

For the fact the rl-arm scheduler requires software triggering of the clock intterupt code just set a breakpoint in "void os_tmr_force_irq (void)" (RTX_lib.c) and you'll see how often this one is called containing the macro OS_TFIRQ() that is just a macro of the above described AT91C_TFIRQ (RTX_Config.c defines them both).

Thanks for all your ideas. Keep sending them. Thanks!!

P.S.: My temporary change from level to edge (see above the multi line AT91C_TFIRQ macro) works long but still not stable (only 01h 45m under full software load)

But does using a timer as interrupt source solve your problem? Maybe you're looking at an entirely wrong direction!

I use the sys irq in level mode so I cannot miss any irq. I do this for all irqs.

Unfurtunality rl-arm's rtx_config.c sets the edge mode but works.

When you use other peripherals that share this sys irq you need (before you may have edge too) to change to level mode (especially for the asyncronously to mck fired rtt). This level works fine but rl-arms scheduler requires triggering by a simple software command of the scheduler for additional runs.

When this additional runs of the rl-arm scheduler are not happen too long internal queues seems to overflow (what is just ignored in rl-arm as much I can see in the source) and this will end to lost messages and for internal queues lost commands (done for any isr_xxx calls of rl_arm like isr_mbx_send etc.)

Thanks for you valuable input. Go on and kick my brain to the right point;-)

Hi there,

just to keep you updated: I made it! The system works now stable in sysirq's level mode and the pit as scheduler tick source - also during high loads so far.

Some of you where right, I needed to make some other works too: Make some forgotten portions of my code real thread safe. I'm sorry I left out three portions in the code size of 25000 lines (without empty ones)...

But on the other hand the current version of the rtx_config.c does _not_ support the sysirq's level mode that is a strict requirement for irq driven use of rtt and other peripherals "wired or" to the sysirq.

I cooperation with support it's now working. But all my "many days" work is paid by my customer and therefore I've not the rights to publish the changes here.

Hopefully the next official version of rtx_config.c will come with sysirq's level mode support which enables you to still use the pit as scheduler tick source and also use the others "wired or" sources of the sysirq like rtt.

Thanks everybody for your kicks, questions, doubts, ideas and patience.

Good luck
Helmut