Доброго времени суток, коллеги.

Итак, ситуация:
Контроллер AT91RM3400.
используются прерывания:
FIQ - по отрицательному фронту на соответствующей ноге контроллера.
таймер - вызывается каждые 100мкс. Обработчик порядка 15-20мкс.
системній таймер - период порядка 250мс.
UART's - прерывания на прием/передачу с 0 приоритетом. (работают нормально)

Все замечательно работало достаточно длительное время.
Сейчас понадобилось внести некоторые доработки, в результате обработчик таймера перестает выполняться через несколько минут работы программы. При этом FIQ, системный таймер и UART'ы продолжают выполняться нормально.
Предполагаю причина в том, что раньше обработчик FIQ выполнялся порядка 80-85мкс. После дополнения, стал иногда выполняться до 103-105мкс. Поставив на вход и выход из обоих обрабочиков дергание ножками, вижу что FIQ может прерывать обработчик таймера.
Поймать непосредственно момент пропадания прерываний таймера осциллографом не удалось. Мне кажется, что это происходит когда FIQ прерывает обработчик таймера, и новое прерывание таймера приходит когда FIQ еще не вернул управление. Может такое быть или надо искать причину в другом?

JTAG или иным отладчиком "залезть внутрь" и посмотреть что происходит возможности нет.

В принципе можно было б даже сделать таймер более приоритетным, но ни один IRQ не может прервать FIQ. а там сигнал который является источником заведен на плате на вывод FIQ и как его понизить до статуса IRQ я не знаю.

Рад буду любым идеям по решению данной проблемы.

Да, забыл - в sturtup на оба вектора стоит
LDR PC,[PC,#-0XF20]
т.е. обработка идет через AIC.

Сообщение отредактировал Shein - Jan 21 2011, 15:55

Прерывание от таймера, случайно, не по фронту срабатывает?

Пропуск прерываний таймера не есть причина для зависания, если только как-то специально не постарались написать.
Смотрите для начала просто размеры стеков и наползание FIQ стека на чужой.

Да по фронту. В битах AIC_SRCTYPE соответствующего регистра AIC_SMR устанавливается значение 3


Я тоже так думаю. Но уом пока не понимаю что может пиводить к прекращению вызовов обработчика.

Стеки увеличил первым делом. Видимого эффекта не дало. Да и при наползании стеков, мне кажется, было бы более неадекватное поведение программы. FIQ может накладываться и на другие прерывания, хоть и с меньшей вероятностью т.к. они реже. Но глюк наблюдается именно с таймером.
Все же надо будет сделать контроль переполнения для FIQ и IRQ стеков...

Сообщение отредактировал Shein - Jan 22 2011, 14:10

Теряете где-то фронт, скорее всего. Переставьте на срабатывание по уровню. Смысла работать с внутренними источниками прерывания по фронту в 99.9% случаев нет ни малейшего.

ну наверное просто привычка срабатывает - ставить срабатывание по фронту. А пропуск фронта может приводить к нарушению логики работы AIC? Ну т.е что он перестанет реагировать на это прерывание?
На данный момент проблема была решена обходным путем: после определенных манипуляций снова уменьшено время обработки FIQ. Но решение-то все равно интересно найти
Попробую поставить по уровню.

Добавлено: Хм... Действительно, поставил по уровню. проблема с пропаданиями ушла. Возможно и теряется какой-то тик таймера, в моем случае это не так критично, главное что он не пропадает насовсем.

Сообщение отредактировал Shein - Jan 24 2011, 14:43

Разумеется. Достаточно по каким-либо причинам не снять источник прерывания перед выходом из обработчика, или же по небрежности сбросить его вручную записью в ICCR, чтобы прерывание больше никогда не регистрировалось AIC'ом.
Для работы по фронту надо иметь веские основания и писать код предельно внимательно.

Век живи - век учись. Спасибо за помощь, впредь буду знать.

Самое удивительное, что про эту особенность (прерывания от внутренних устройств только по уровню) Atmel'овских процессоров на нашем форуме уже столько раз писалось. Ан нет. Поиском пользоваться ни в какую.

Охотно верю что я не один такой Поиком пользовался (возможно плохо, но все же). Просто проблемы с одной и той же причиной кождый может описать по своему. Зачастую трудно вычленить что имено ты ищешь. Сейчас, зная уже причину, гораздо проще найти что об этом уже писалось но уже не нужно.

Самое интересное, что сам Атмел про эту особенность ничего не знает. Более того, в описании они явно указывают:Давайте разберемся, каким образом пропуск фронта прерывания при корректной обработке остальных источников может вызвать "отваливание" обработчика. Я не вижу объективных причин, возможно я чего-то недопонимаю.

Две возможных причины я указал:
1. Источник прерывания не был снят в обработчике. Линия осталась в активном уровне, никаких фронтов на ней уже не будет.
2. "Случайная" запись ICCR при активном прерывании приведет к тем же последствиям.

В обоих случаях виноват, разумеется, код и его автор. Но частота возникновения подобных "граблей" почему-то совсем не удивляет.
Если уж человек не задается вопросом зачем именно ему нужно прерывание именно по фронту, то не стоит ждать и тщательного прогнозирования последствий такого неосознанного выбора