Выручай всезнающий Олл!

ATmega 16L проблема с UART, а именно после посылки всего, когда буфер уже пустой возвращается из интерапта на начало программы (фактически рестарт). Код прерывания


Что я делаю не так. При просмотре в Студии в режиме ассемблега, видно что в переходе на прерывание все пакуется в стек, потом также аккуратно распаковывается, и возвращается по команде RTI, но почемуто в старт?

Може кто с таким эффектом сталкивался?

Не понял - вы увидели, что правильный адрес возврата в стеке лежит, а возвращается в 0? Или адрес возврата никто в стек и не клал? Что значит "в переходе на прерывание"?

ИМХО, стек переполнился.

Переопустошился (или как это будет по русски?).

Все-таки переполнился.
Возможность зануления адреса возврата есть только на этой строке:

USART0_TX_Tail = temp_tail;


После линковки создается отчет по расходу памяти. Посмотрите сколько памяти данных у Вас занято?

(все что остается - отдается под стек, я не позволяю себе оставлять под стек меньше 256 байт).

Вот это скорость ответов на форуме! Супер!

К теме


Занятость:
Data: 383 bytes (37.4% Full)

Чем может переполниться стек, если программа только получает и отсылает по 5-7 Байт?

Так Вы в Студии и проконтролируйте стек: состояние стека и содержимое его когда вошли в прерывание, и когда выходите (перед RTI). Должно быть одним и тем же.

указатель стека при входе и выходе не отличаются, короче. сколько запаковывается, столько же и распаковывается. Содержания стека я в студии не нашел. Может подскажешь, палычь, где оно в студии зарыто?

+1
И регистры должны то-же значение иметь, и адрес возврата в стеке д.б.
Вы в прерывание как входите? М.б. вы просто адрес возврата в стек не кладёте? Надо при отладке call/rcall команду на таблицу прерываний делать.

Опа?! А вот с этого места по подробнее. Я всю жизнь думал, что при вызове прерывания адрес возврата сохраняется автоматически в стек. Если это не так, то как это делается и в каком месте. Я же не знаю в какой момент прерывание произойдет. Где этот код распологать?

Правильно думали.

Это только для отладки. А как у вас прерывание от USART при отладке вызывается?

А чтоб стек проконтролировать - надо ОЗУ начиная с адреса указателя стека посмотреть.

Действительно, обработчик прерывания, фрагмент кода которого Вы привели использует 9 байт стека. Но стек также использует и основная программа: для адресов возврата из вызываемых подпрограмм, для размещения локальных переменных и массивов, передачи параметров процедурам и функциям... Разные трансляторы используют стек по-разному. Я плохо знаком с WinAVR, и не могу сказать - что со стеком делает он... Но, во всех трансляторах (ИМХО) самые прожорливые до памяти функции - printf, scanf и им подобные. Используете ли Вы подобные процедуры? Есть ли в Вашей программе большие локальные массивы? Стек распалагается в памяти - для просмотра можно использовать окно Memory. Делать искуственный вызов процедуры прерывания из программы не надо - достаточно "пошевелить" флаги - само произайдёт. Кстати, Вы ведь умудрились увидеть как-то вот это Как? Ну, так сделайте это же ещё раз с контролем стека.
P.S. Последняю цитата, может быть, говорит только о том, что Вы увидели в окне команды push/pop/reti? Тогда, как Вы определили, что именно по reti этого обработчика программа попала на нулевой адрес?

Переход осуществляется на адресс указанный в стеке. Странно только,что команда RTI ситает из стека 2 байта (0х20 0хЕ8) а переходит на 0хЕ8. Но такого адресса 0х20Е8 или 0хЕ820 все равно нет. В стеке все нормально, до переполнения ему еще очень долеко, там всего 38 байт.

Возможно, Вы не учитываете то, что Stack Pointer указывает на свободную ячейку: содержимое стека - выше. Т.е., если возврат на 0х00Е8, то в ячейке +1 должен быть 00, в ячейке +2 должно быть Е8.
Отчего всё же Вы решили, что на адрес 0 попадаете по reti из этого обработчика?

потому-что после reti программа переходит вот сюда


теперь это Е7.