|
MSP430F20xx и потерянные прерывания, MSP430F20xx "теряет" прерывания, которые заведены на один и то |
|
|
|
Feb 16 2009, 08:17
|

Знающий
   
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065

|
Будьте осторожны: MSP430F20xx имеет тенденцию "терять" прерывания, которые приходят на один порт.
Дано MSP430F2001. На одной ноге порта P1 висит хронирующая RC-цепь, на другю ногу приходят извне импульсы. Процессы на ногах никак не синхронизированы.
Хронирующая RC-цепь является времязадающей для посторения НИзкочастотного генератора (примерно 1 кГц), который "будит" проц. Цепь состоит из конденсатора 470 пФ и резистора 2.4 МОм, которые вторыми выводами сидят на земле. Работа генератора достаточно простая -- проц "поворачивает" линию порта, выводит единицу (т.е. заряжает конденсатор), и вновь "поворачивает" линию на ввод. Порт организаван так, что при снижении напряжения на выводе возникает прерывание. Это прерываение пробуждает процессор, который запускает свой внутренний тактовый генератор и работая на большой скорости снова подзаряжает конденсатор. После чегог снова засыпает.
Таким образом, работает очень низкочастотный генератор и мы имеем очень незначительное энергопотребление. Практика показывает, что при правильном проектировании печатной платы и источника питания такая, на первый взгляд, вроде бы сомнительная ситема тактирования, -- работает достаточно надежно. Прогоны девайсов по нескольку суток не выявили никаких зависаний.
Вторая нога порта P1 -- на нее приходят внешние импульсы, которые надо просто посчитать. Ничего необычного, ничего интересного. Уточню только, что поступление на ножку нарастающего форнта импульса пробждает проц. Во время обработки проц тактируется от внутреннего генератора, как и в первом случае. Инкрементировав счетчик импульсов проц снова засыпает.
Проблема Когда указанная работа производилась разными портами, т.е. хронирующий генератор на P1, а внешние прерывания на P2, то все работало очень даже хорошо.
Лучшее -- враг хорошего! Решил развести плату более "правильно". Обе функции возложил на один порт. В начале обработчика прерывания сделал фильтр -- определял от какой ноги возникло прерывания, и выполнял соответствующие действия. Если были подняты оба флага прерывания, выполнял оба действия.
Пока внешние импульсы были редкими, все работало. Как только частота импульсов стала примерно 10 имп/с, начались зависания хронометра. Внешне выглядело так, как будто проц пропускал спадающий фронт RC-цепи и соответственно не подзаряжал конденсатор.
Всяческие "капканы", обильно расставляемые в коде обработчика прерывания, не дали никакого результата. Мне неудалось выловить пропуск прерывания от хронометра, хотя эпизодические зависания продолжали возникать.
Мое объяснение такое, что когда вызывался обрабатяик прерывания по внешнему импульсу, но еще в обработчике не успевала выполниться команда опроса регистра прерывания порта, возникало условие прерывания от хронометра, флаг выставлялся. Затем в коде считывалася регистр прерываний, где были установлены оба флага. Код честно отрабатывал обе функции и так же сбрасывал оба флага. Видимо, после этого следующий фронт от хронометра уже не мог вызывать обработчик прерывания, в результате конденсатор разряжался уже до нуля и более ниспадающих фронтов уже не могло появиться. Генератор останавливался.
Возвращение прерываний "на родину", т.е. разведение их по разным портам и, соответственно, разнесение функционала по разным обработчикам прерываний устраняло пролему.
Вывод Согласно выше изложенному, я утверждаю, что MSP430F20xx имеет очень нехорошую особенность в обработке прерываний, которые заведены на один и тот же порт.
и еще Я не проводил более "глубинных" исследований. Я не пробовал воспроизвести ситуацию на других процах. Я всего лишь описал ситуацию, с которой пришлось столкнуться лично мне и потерять определенное время. Я просто предупреждаю -- типа будьте бдительны, не наступайте на мои грабли!
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
|
 |
Ответов
|
Feb 17 2009, 02:28
|
Гуру
     
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882

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

Знающий
   
Группа: Свой
Сообщений: 723
Регистрация: 29-08-05
Из: Березовский
Пользователь №: 8 065

|
Цитата(rezident @ Feb 17 2009, 07:28)  Причина ее в том, что флаги порты P1 и P2 имеют по одному вектору прерывания с индивидуальными флагами на каждый бит. Для того чтобы сбросить флаг прерывания нужно записать нуль в соответствующий бит регистра PxIFG. Однако механизма манипуляции отдельными битами в архитектуре MSP430 нет. Приходится накладывать маску и писать целиком весь регистр PxIFG. Команда bic.b #XX, &PxIFG. именно так и делает. Если в момент записи в регистр произойдет событие, которое должно было вызвать прерывание, то оно будет потеряно. Согласуется с тем, что я наблюдаю. Очень походит на правду, похоже ничего TI не сделала с портами. А жаль!
--------------------
Хочешь рассмешить Бога -- расскажи ему о своих планах!
|
|
|
|
|
Feb 17 2009, 16:34
|
Гуру
     
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882

|
Цитата(zhevak @ Feb 17 2009, 11:12)  Согласуется с тем, что я наблюдаю. Очень походит на правду, похоже ничего TI не сделала с портами. А жаль! А вы не расстраивайтесь раньше времени, а лучше в напишите баг-репорт в суппорт TI. Любопытно, что они ответят.  Кстати, бояться обращения в службу тех.поддержки не нужно. Пишите по-русски смело. В европейском суппорте (который в Чехии) работают трое русскоязычных товарищей. Они даже очень рады, что к ним обращаются. Правда, если вы им очень приглянетесь (как потенциальный заказчик с крупно-мелкой серией), то могут потом задолбать с просьбами составить и прислать им ваши планы потребления продукции TI на весь год
|
|
|
|
Сообщений в этой теме
zhevak MSP430F20xx и потерянные прерывания Feb 16 2009, 08:17 MrYuran Не раскрыта тема обработки источника прерываний.
К... Feb 16 2009, 08:22 zhevak Цитата(MrYuran @ Feb 16 2009, 13:22) Не р... Feb 16 2009, 08:38 MrYuran Вообще в руководстве сказано, что прерывания, возн... Feb 16 2009, 09:17 zhevak Цитата(MrYuran @ Feb 16 2009, 14:17) Вооб... Feb 16 2009, 09:40 MrYuran Кстати, интересно, насколько такой режим (внешний ... Feb 16 2009, 09:52 zhevak Цитата(MrYuran @ Feb 16 2009, 14:52) Кста... Feb 16 2009, 10:14 bloodden У 2274 я такого не наблюдал. Было два внешних, пол... Feb 16 2009, 12:39    rezident Цитата(Dog Pawlowa @ Feb 17 2009, 21:54) ... Feb 17 2009, 17:07 sensor_ua В проекте F2013 и должен работать с P1IFG. И надеж... Mar 19 2009, 15:19 rezident Цитата(sensor_ua @ Mar 19 2009, 20:19) Не... Mar 19 2009, 20:35 sensor_ua ЦитатаXOR ... является атомарной операцией.
Я не ... Mar 19 2009, 20:59 rezident Цитата(sensor_ua @ Mar 20 2009, 01:59) ти... Mar 19 2009, 21:23
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|