MSP430F20xx и потерянные прерывания, MSP430F20xx "теряет" прерывания, которые заведены на один и то Опции

[zhevak]

Будьте осторожны: MSP430F20xx имеет тенденцию "терять" прерывания, которые приходят на один порт.

Дано
MSP430F2001. На одной ноге порта P1 висит хронирующая RC-цепь, на другю ногу приходят извне импульсы. Процессы на ногах никак не синхронизированы.

Хронирующая RC-цепь является времязадающей для посторения НИзкочастотного генератора (примерно 1 кГц), который "будит" проц. Цепь состоит из конденсатора 470 пФ и резистора 2.4 МОм, которые вторыми выводами сидят на земле. Работа генератора достаточно простая -- проц "поворачивает" линию порта,
выводит единицу (т.е. заряжает конденсатор), и вновь "поворачивает" линию на ввод. Порт организаван так, что при снижении напряжения на выводе возникает прерывание. Это прерываение пробуждает процессор, который запускает свой внутренний тактовый генератор и работая на большой скорости снова подзаряжает конденсатор. После чегог снова засыпает.

Таким образом, работает очень низкочастотный генератор и мы имеем очень незначительное энергопотребление. Практика показывает, что при правильном проектировании печатной платы и источника питания такая, на первый взгляд, вроде бы сомнительная ситема тактирования, -- работает достаточно надежно. Прогоны девайсов по нескольку суток не выявили никаких зависаний.

Вторая нога порта P1 -- на нее приходят внешние импульсы, которые надо просто посчитать. Ничего необычного, ничего интересного. Уточню только, что поступление на ножку нарастающего форнта импульса пробждает проц. Во время обработки проц тактируется от внутреннего генератора, как и в первом случае. Инкрементировав счетчик импульсов проц снова засыпает.

Проблема
Когда указанная работа производилась разными портами, т.е. хронирующий генератор на P1, а внешние прерывания на P2, то все работало очень даже хорошо.

Лучшее -- враг хорошего! Решил развести плату более "правильно". Обе функции возложил на один порт. В начале обработчика прерывания сделал фильтр -- определял от какой ноги возникло прерывания, и выполнял соответствующие действия. Если были подняты оба флага прерывания, выполнял оба действия.

Пока внешние импульсы были редкими, все работало. Как только частота импульсов стала примерно 10 имп/с, начались зависания хронометра. Внешне выглядело так, как будто проц пропускал спадающий фронт RC-цепи и соответственно не подзаряжал конденсатор.

Всяческие "капканы", обильно расставляемые в коде обработчика прерывания, не дали никакого результата.
Мне неудалось выловить пропуск прерывания от хронометра, хотя эпизодические зависания продолжали возникать.

Мое объяснение такое, что когда вызывался обрабатяик прерывания по внешнему импульсу, но еще в обработчике не успевала выполниться команда опроса регистра прерывания порта, возникало условие прерывания от хронометра, флаг выставлялся. Затем в коде считывалася регистр прерываний, где были установлены оба флага. Код честно отрабатывал обе функции и так же сбрасывал оба флага. Видимо, после этого следующий фронт от хронометра уже не мог вызывать обработчик прерывания, в результате конденсатор
разряжался уже до нуля и более ниспадающих фронтов уже не могло появиться. Генератор останавливался.

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

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

и еще
Я не проводил более "глубинных" исследований. Я не пробовал воспроизвести ситуацию на других процах. Я всего лишь описал ситуацию, с которой пришлось столкнуться лично мне и потерять определенное время. Я просто предупреждаю -- типа будьте бдительны, не наступайте на мои грабли!

[MrYuran]

Вообще в руководстве сказано, что прерывания, возникшие во время обработки прерываний, теряться не должны...
Хотя, если выставляется прерывание, которое в данный момент обрабатывается ... могут быть накладки.
У меня подобные глюки были при одновременной обработке прерываний с разных CCR таймера В.
Проблема (с пропуском) решилась шаманством с разрешением(или запрещением?) вложенных прерываний.

Можно попробовать 2 варианта.
1. Поиграться с разрешением/запрещением прерываний внутри обработчика
2. При обработке внешнего сигнала (счетчик УФ-импульсов) просматривать состояние пина таймера, и если оно нулевое - дёргать ногой.

Ещё, по-моему, вашу программу можно сократить на команды усыпления и пробуждения, т.к. loop фактически ничего не выполняет, да и вообще туда программа никогда не переходит

[zhevak]

Вообще в руководстве сказано, что прерывания, возникшие во время обработки прерываний, теряться не должны...

Вот именно! Я на это же повелся, гы-гы!

Можно попробовать 2 варианта.
1. Поиграться с разрешением/запрещением прерываний внутри обработчика
2. При обработке внешнего сигнала (счетчик УФ-импульсов) просматривать состояние пина таймера, и если оно нулевое - дёргать ногой.

1. Не канает. При заходе в обработчик прерывания флаг разрешения прерываний уже сброшен. А если Вы имеете ввиду отключать разрешения прерывания в порту -- то, тоже не канает. Во-первых, время от возникновения первого прерывания до запрещений (или как в мем случае -- до считывания флагов прерываний регистра порта) -- не нулевое, т.е. ничто не может гарантировть поднятие флага второго прорывания в этот момент. Т.е. грабли все равно остануться. А во-вторых, отключать прерывания нельзя, на них работа основана.
2. Тоже не канает. УФ-импульсы могут вообще не приходить! А таймер должен тикать раз в миллисекунду. И наоборот, если в прерывании от хронометра просматривать состояние УФ. УФ-импульсы очень короткие (30-70 мкс), и между тиками хронометра их может придти несколько.

Ещё, по-моему, вашу программу можно сократить на команды усыпления и пробуждения, т.к. loop фактически ничего не выполняет, да и вообще туда программа никогда не переходит

Ага, согласен, -- можно. Но, пока не нужно.
Оно меня пока никак не напрягает, т.к. у меня запаса флеши еще предостаточно, да и вероятность того, что придется использовать цикл, имеет место быть. Так что, пусть будет.

Сообщение отредактировал zhevak - Feb 16 2009, 09:47