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

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

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

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

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

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

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

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

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

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

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

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

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

Не раскрыта тема обработки источника прерываний.
Как именно всё происходит?

Ну вот тут "приартачен" асмовский файл. Лишнее поубирал, комментариев добавил.

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

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

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

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

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


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


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

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

Кстати, интересно, насколько такой режим (внешний RC-будильник) выгоднее таймера А и часового кварца?
Какое среднее потребление удалось получить?
ЛПМ4 в таком режиме можно применять?

Точно сказать не могу, т.к. не измерял чистое потребление МК. Если Вас интересует порядок, то несколько десятков мкА (от 10 до 40). Но, опять же, слепо сравнивать нельзя. Ведь ничего не потребляющий проц -- ничего поелного делать не может. А если что-то будет делать, то по любому расход "топлива" будет обязательно.

Помимо низкого энергопотребления девайс должен уметь формировать на одной из лапок короткие импульсы, порядка единиц мкс и пихать их в затвор полевика (как следствие, питалово проца должно быть -- чем больше, тем лучше, что не есть хорошо с точки зрения экономии). Т.е. тактовая частота должна быть в районе мегагерца и более. Я решил не резвиться с динамической перестройкой внутреннего RC-генератора: одна частота для хронометра и спячки, другая -- для бодрствования. Хотя, будет время, обязательно поиграюсь. Сейчас у меня в режиме спячки все генераторы отрублены. Проц практически вообще ничего не хавает.

У 2274 я такого не наблюдал. Было два внешних, полностью асинхронных сигнала - всё пучком.

В серии MSP430x13x/14x эта проблема была описана в Errata под кодом PORT3.
Причина ее в том, что флаги порты P1 и P2 имеют по одному вектору прерывания с индивидуальными флагами на каждый бит. Для того чтобы сбросить флаг прерывания нужно записать нуль в соответствующий бит регистра PxIFG. Однако механизма манипуляции отдельными битами в архитектуре MSP430 нет. Приходится накладывать маску и писать целиком весь регистр PxIFG. Команда bic.b #XX, &PxIFG. именно так и делает. Если в момент записи в регистр произойдет событие, которое должно было вызвать прерывание, то оно будет потеряно.
В более поздних MSP430x15x/16x и в серии MSP430x2xx этого бага (PORT3) в Errata нет. На блок-схеме пинов портов P1 и P2 изменений в логике тоже не наблюдается. Так что для меня остается загадкой, как именно решили (и решили ли вообще?) эту проблему в TI? Было бы наверно логично сделать механизм как в AVR: сброс установленных битов прерываний происходил бы при записи в соответствующие разряды лог.1, а не лог.0.

Согласуется с тем, что я наблюдаю. Очень походит на правду, похоже
ничего TI не сделала с портами. А жаль!

А вы не расстраивайтесь раньше времени, а лучше в напишите баг-репорт в суппорт TI. Любопытно, что они ответят. Кстати, бояться обращения в службу тех.поддержки не нужно. Пишите по-русски смело. В европейском суппорте (который в Чехии) работают трое русскоязычных товарищей. Они даже очень рады, что к ним обращаются. Правда, если вы им очень приглянетесь (как потенциальный заказчик с крупно-мелкой серией), то могут потом задолбать с просьбами составить и прислать им ваши планы потребления продукции TI на весь год

Был же индус специально для России. Или это было давно?

В июне прошлого года общался и мылом и по телефону с Анатолием Буториным (Европейский Центр Поддержки Клиентов, Texas Instruments Deutschland GmbH). Если он индус, то я - Папа римский Сейчас они вроде в Чехии, а не в Германии обитают.

В проекте F2013 и должен работать с P1IFG. И надежда была на безглючный кремний;(
Интересно, может, подобная конструкция поможет?
149 P1IFG_raw = P1IFG;
\ 000000 D2422300.... MOV.B &0x23, &P1IFG_raw
150 P1IFG ^= (unsigned char)(P1IFG_raw);
\ 000006 D2E2....2300 XOR.B &P1IFG_raw, &0x23

Не знаю как XOR работает по факту - прям в порту или опять же пишет после модификации

Насколько я помню, XOR относится к группе Double Operand Instructions и является атомарной операцией. Так что решение вполне корректное.