Доброго времени суток народ

Столкнулся с проблемами в AVR Studio 5.

1. При отладке в дебаге на железе, в следующие процедуре
void main()
{
<операции инициализации>
for(;;)
{
<основной бесконечный цикл>
}
}
по идее программа должна крутится в бесконечном цикле оператора for. А она крутится то в main то в for.

2. Есть серия операций присвоения констант структуре в ходе выполнения программы.
E2.IDCode[0]=0xAF;
E2.IDCode[1]=0x5B;
E2.IDCode[2]=0x8D;
E2.IDCode[3]=0x5A;
E2.IDCode[4]=0x3D;
E2.IDCode[5]=0x91;
E2.IDCode[6]=0x00;
ассемблерный листинг от компиляции к компиляции может выкидывать инициализацию переменным с IDCode[2] по IDCode[6]
3. В проекте используются прерывания аппаратных модулей авр. Существует ситуация, когда при приходе прерывания в структуру данных, объявленную глобально, записывается некая информация - буквально байт. При приходе следующего прерывания этот байт самопроизвольно очищается, причем в теле обработчика прерываний эта область памяти не используется и операций с ней не проводится. Дебаггер показывает, что память портится именно в тот момент, когда приходит следующее прерывание.
ПыСы
Если тупо попытаться исключить ошибки дебаггера, и залить скомпиленую прошивку в авр, то глюки присутствуют -* авр не фурычит. А если идти по Ф11 по коду в процессе отладки то перечисленные баги 1 и 2 можно раза с третьего(с третьей компиляции) избежать, а вот третий баг вообще не поддается.
ПыСыСы
Проект портирован из IAR. И без ошибок компилится. Только вот неправильно

Поможите ! Может кто сталкивался с этими вещами ?

Сообщение отредактировал egor_spqr - Jan 19 2012, 05:35

Стек маловат.

Или не -Os

поподробнее пожалуйста про стек. что вы имели ввиду, и если не трудно, применительно к AVR Studio 5

по поводу ключей компилятора: пробовал и без оптимизации - не помогает

С AVR Studio не работаю, но если там есть способ указать размер стека, то это следует сделать (увеличить).
Обычно указатель стека инициализируется адресом верха ОЗУ.
Вообще то, если Вы отлаживаетесь на железе, то можете увидеть причину порчи переменных.

Как раз без оптимизации - самое и убьёт, не только не поможет.


Кстати, если с консолью - можно выводить значение SP из прерывания. Реалтайм, правда, не пойдет.

В GCC (WinAVR) стек обычно движется навстречу переменным. Увеличить его можно, только уменьшив количество используемых глобальных и статических переменных.

Предложу ещё два магических заклинания:
1. volatile для переменных, изменяемых в прерываниях
2. __attribute__((used)) для структуры, чтобы её не коцал компилятор. Или тоже volatile, если выкидывает обращения к полям

А ещё лучше почитать документацию к WinAVR, там наверняка все тонкости оговорены отдельно

Привет всем ишшо разик.
Значится так:

проблемы 1 и 3 оказались взаимосвязанными! Как показал дебаг в дисассемблере, AVR Studio не смогла корректно обработать неиспользуемые вектора внутренних прерываний.
В частности: инициализирован таймер, но вектор прерывания не описан, в этом случае процессор просто резетится.

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

вообще-то говоря, что касается обработчиков прерываний - это очевиднейшая вещь

Странно, что WinAVR не ставит заглушки.
MSPGCC - ставит по умолчанию вектор _unexpected_

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

Заглушка есть (именно в стартап-файле) и называется __bad_interrupt.
Но она по умолчанию делает рестарт программы с адреса 0 (делает переход на weak-метку __vector_default)

Можно в своём коде ловушку переопределить
и в ней сделать свои действия, корректно сворачивающие работу и, к примеру, мигающие светодиодом «караул».
Но ведь для этого надо сначал почитать документацию на WinAVR, описание библиотеки, файла avr/interrupt.h, параграфа «Catch-all interrupt vector». Гораздо проще документацию не читать, а при проблемах обвинять компилятор, он-де «неправильно собирает».