Возможно ли включить прерывание по переполнению таймера при задействовании PWM ?
Вот код :


А если сделать так:

То попадая в прерывание мк выполняет то что там написано по кругу и из прерывания не выходит. Что я делаю не правильно?

У Вас неверно задан вектор прерывания. Для прерывания по переполнению используется TIMERA1_VECTOR (см. раздел "Timer_A Interrupts" в юзергайде)

Спасибо, просмотрел указанный раздел юзергайда , но так все равно не работает.
Если не включаю PWM то все работает как надо, не получается использовать прерывание по переполнению при задействованном PWM.

01 Режим «вверх»: таймер считает вверх к TACCR0
О каком переполнении может идти речь?

В этом режиме прерывание от переполнения все равно генерируется, TAIFG устанавливается при переходе от совпадения CCR0->0. См. скриншот из User's Guide.
Проблема скорее всего в том, что топикстартер неправильно обработчик вектора TIMERA1_VECTOR написал (мы-то ведь этот код не видели). TIMERA1_VECTOR расшарен для трех источников прерывания CCR1 CCIFG, CCR2 CCIFG и TAIFG. Поэтому нужно использовать TAIV внутри обработчика так, как это описано в User's Guide.

Судя по коду, CCR1 и CCR2 прерывания не формируют (выключен CCIE)
Кстати, с CCR0 тоже неочевидно (не видно инициализации CCTL0)

Если всё время сидит в прерывании, значит, либо вызывается TIMERA1_VECTOR и не считывается TBIV (предположительно), соответственно CCIFG остаётся стоять и вызывает прерывание опять.
Ещё возможно, что определён один вектор, а вызывается другой, соответственно программа улетает в неведомую даль. (опять же, предположение)

Очень может быть. Нарывался на это как-то.

Насколько я понял, "все время сидит в прерывании" относится к первому варианту с обработчиком вектора TIMERA0_VECTOR. Считывание TAIV при этом ни при чем, т.к. TACCR0 CCIFG, в отличие от остальных, сбрасывается автоматически при переходе на вектор TIMERA0_VECTOR. Думаю, что дело в другом. Это особенности работы дебаггера C-CPY в IAR. Я такое тоже замечал. Иногда дебаггер все время начинает вылетать в какое-то таймерное прерывание (которое у меня вызывается периодически), несмотря на то, что breakpoint стоит совсем в другом месте. Помогает либо перезапуск, либо последовательность действий: снять все breakpoint, отпустить устройство "в свободный полет" и затем снова установить breakpoint.
А насчет "не считывается TAIV" я уже написал выше

фтопку дебаггер...
я поигрался как-то полчасика, словил пару глюков и с тех пор житаговые ноги свободны

Спасибо всем за помощь.


Так правильно?

Если можно обясните почему 2,4,10 ? К чему относятся эти числа?


Как побороть? Сбросить вручную CCIFG не получается.... IAR матерится....

Сообщение отредактировал Left Radio - Jul 7 2009, 16:38

Вполне.
А вы User's Guide читать не пробовали?
"Вручную" это как? Записью в TAIV? Дык он же read-only! У вас все верно в примере написано, поэтому ничего "вручную" сбрасывать не нужно. Еще раз советую внимательно читать User's Guide. Хотя бы в раздел описания регистров Timer_A загляните.

Спасибо понял, все заработало Причиной была моя невнимательность

Сообщение отредактировал Left Radio - Jul 7 2009, 17:21

К моему стыду, Вы правы. Недосмотрел.... :-(

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

первые 2 кейса можно было и не писать, так как они всё равно пустые.
ТАIV определяет, какой сигнал вызвал прерывание TIMERA1_VECTOR.

Очень удобно, что "проградуирован" он через 2.
Можно очень просто организовать таблицу переходов (описано в руководстве), либо в ИАРе есть такая примочка для кейса - Even_in_range(), которая оптимизирует switch/case, если аргумент чётный и входит в ограниченный диапазон. Фактически, формируется та же таблица переходов. В прерывании бывает очень актуально.