реклама на сайте
подробности

 
 
> Почему может не срабатывать прерывание таймера по сравнению в Atmega128?
Непомнящий Евген...
сообщение Sep 9 2015, 08:25
Сообщение #1


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



IAR, Atmega128

В программе есть переход в некий специальный режим. До перехода прерывание timer3CompareC работает - ставлю бряк в отладчике - попадаю в обработчик. После перехода - не работает. Содержимое регистров таймера 3 после перехода - на скриншоте, ничего криминального не вижу (OCIE3C стоит, OCF3C стоит, таймер работает, TCNT3 меняется, SREG I стоит). Программа в это время крутится в основном в for(;;); в конце main().

Прикрепленное изображение

Прикрепленное изображение


Есть еще аналогичное прерывание timer1CompareB, так оно работает maniac.gif

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

Не могу понять, что такое могло испортиться, чтобы не работало прерывание?
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов (1 - 3)
Непомнящий Евген...
сообщение Sep 9 2015, 10:14
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



upd Расследование показало, что отваливаются прерывания таймера по сравнению 1С, 3A, 3B, 3C. А вот 1A и 1B работают. Т.е. не работают те, которые настраиваются в ETIMSK

Контрольный список - почему не срабатывает прерывание
* SREG/I - включен
* Флаг самого прерывания в ETIMSK - включен
* Условие прерывания - сработало, бит в ETIFR установлен
* Постоянно срабатывает прерывание с более высоким приоритетом - у меня это явно не так, если исполнять по шагам - отладчик крутится в for(;;); в main()
* Перенесена таблица прерываний (MCUCR / IVSEL) - нет, IVSEL сброшен. К тому ж некоторые прерывания работают
* Что-то еще?

Блин, вот такое чувство, что включается Atmega103 compatibility mode, но ведь его нельзя установить программно, только через программатор?
Go to the top of the page
 
+Quote Post
Gorby
сообщение Sep 9 2015, 10:37
Сообщение #3


Местный
***

Группа: Свой
Сообщений: 449
Регистрация: 28-10-04
Из: Украина
Пользователь №: 1 002



Цитата(Непомнящий Евгений @ Sep 9 2015, 14:14) *
* Что-то еще?


Убедитесь, что в ERRATA не упоминается такой случай.

Убедитесь, что в настройках компилятора выбран правильный процессор (при неверном выборе всё "как-бы" работает, но не так).

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

Удачи.


--------------------
Умею молчать на 37 языках...
Go to the top of the page
 
+Quote Post
Непомнящий Евген...
сообщение Sep 9 2015, 12:40
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 771
Регистрация: 16-07-07
Из: Волгодонск
Пользователь №: 29 153



"Постоянно срабатывает прерывание с более высоким приоритетом " - как раз мой случай sm.gif При переходе в мой специальный режим включалось прерывание EE_READY, а сам обработчик отсутствовал. Приоритет у него как раз пониже 1A/1B и повыше 1С/3A/3B/3C

Кстати в режиме disassembly студия даже показывает попадания в этот вектор
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 23rd July 2025 - 17:23
Рейтинг@Mail.ru


Страница сгенерированна за 0.01369 секунд с 7
ELECTRONIX ©2004-2016