interrupts

As Per Westermark mentioned in the following post, a level triggered interrupt that remains asserted can cause havoc. That can happen even if a peripheral is shutdown!
It will "cause havoc" even if polled.

Erik

I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'

Now I am probably a little fish when compared to you, but yesterday I had a discussion with a colleague that worked for a company making communication equipment for trains and she seemed to contadict the above statement. In their products, when digital control is gone (processor fried, some software failure) they switch to analog control driven by a small CPLD, which has very limited capabilites indeed (due to hardware cost).

so the "digital control" is failsafe and if it fails the rest works with "limited capabilites".

where is the contradiction.

Most radio stations have a backup transmitter, a backup is not the main working with limited capabilities, it is a backup (which may have less power).

Erik

which is, of course, true. but it won't if it is edge triggered :)

Agreed, but consider the following: if your main controller and the backup run the same code and are generally the same system, it is very possible the even the backup will not deal well with the conditions that killed daddy (given that it is a software failure, of course). example? The Arian 5 self destruction...

It will "cause havoc" even if polled.

No. A polling loop will/may run slower, but will continue to run. It is only the loop time that controls how often the signal gets polled. It is only when/if the program contains something silly like:

while (signal_x_active) process_signal_x();

that it gets into troubles if the signal is stuck.

A constantly generated interrupt will totally kill anything that hasn't higher priority than the interrupt. The main loop may not get enough processor time to be able to notice the stuck interrupt.

Since the majority of applications perform most of their jobs outside of interrupts, they are very sensitive to a interrupt handler constantly being trigged.

Per,
You are right, but frankly, most of the embedded code I have seen so far does not take into consideration that a signal might "get stuck". I have to admit - I don't always check that either. I do when there is functional reason to do so - a signal remaining high for too long may indicate that the machine is experiencing some mechanial failure, and then I indicate an error and stop everything to prevent somebody from being squashed...

most level triggered interrupts reset "the level" in the ISR.
in such a case it is easy to check if the reset "worked" and take action if not.

The exception to the above is some derivatives requirement for a wake up interrupt, but similar detection can be done there.

THUS, even a level triggered interrupt can be detected stuck and disabled.

Erik

Erik,

you wrote

The exception to the above is some derivatives requirement for a wake up interrupt, but similar detection can be done there.

what is a wake interrupt in this context? what do you mean?

read any datasheet for modern derivative that can be woken up from sleep mode by e.g. int0. I recall none that will wake up fron an edge int, all I recall require a level int to wake up.

Erik

Ah, I understand what you meant.