Начал подглючивать девайс при работе. Долго искал причины, пока не убедился, что это косяк IAR ARM 5.30. Делал оптимизацию High по Speed. Были установлены все птички, кроме Static clustering. Окончательно убедился, что это не ошибка в коде, когда стал регулярно ловить такую ситуацию. Ассемблерный код:
...
MOVNE R8,R8, LSL #+16
MOVNE R8,R8, ASR #+16
// 1740 if (a >= wbNOISE_PARTS)//фиксируем начало зубца
CMP R8,#+12
...
Команды MOVNE выполняют преобразование типа short->long. После этих операций в старших 16 битах может быть только знак, т. е. нули или единицы. Когда я ходил по ассемблерному коду, поймать не удавалось. А если идти по С-шному, то после очередного шага я сразу попадаю на строку CMP и вижу чудеса: например, в R8 вместо числа 58, лежат нули в младших 16 битах и число 25 в старших. Посмотрел, как используется R8 в прерываниях, но криминала не обнаружил. Так и не выяснил, что же именно происходит. Но поскольку использованием регистров рулит компилятор, то видимо из-за него когда-то что-то происходит не так.
После снятия галочки Function inlining в настройках оптимизатора все стало работать нормально.

Слова-слова... А где, собственно тот самый не работающий сишный исходник и полученный из него листинг?

прикрепляю файлик, сменил расширение с .s на .txt, а то не позволяли прикрепить
строка 6922
Только код работает, смотреть его, наверное, неинтересно. Исходник не менялся полтора года, прошивка столько же работает в серийных изделиях. Я три дня по этому коду хожу. При одних и тех же начальных условиях функция может работать по-разному. А тот фрагмент, который написан выше, вроде как однозначно определяет содержимое R8.

Ну тогда и смотреть не буду, если к коду претензий нет.

Может я чего-то не понимаю, но MOVNE выполняется именно когда NE. А если перед этим кодом получилось не NE, то эти команды не выполняются, и никакой однозначности в определении содержимого R8.

В этом месте в листинге всё в норме

Никакой неоднозначности. В зависимости от R6 у регистра R8 (signed short) будет сменён знак и опять преобразован к signed short (на всякий случай (+0x8000)).
---------
Насколько я успел мельком взглянуть, в листинге не видно баг и там не может быть старшие 16 бит R8 содержать число отличное от 0 или 0xffff.

Сообщение отредактировал GetSmart - Nov 23 2009, 11:58

Одно только в этом коде выглядит подозрительным

При входе в цикл регистры R2 и R10 будут изначально равны и цикл по сути не выполнится ни разу. Видимо из-за первых двух одинаковых параметров на вызове
a = wbCalcDA(wv->ind_new, wv->ind_new, minus, wseg);

Если же есть явное подозрение на порчу R8, то это ещё может быть из-за неправильного сохранения/восстановления регистров в прерывании. Например прерывание обрабатывается в IRQ режиме, а обработчик оформлен с помощью __fiq атрибута. И ещё прикольный баг может быть - если вложенное прерывание некорректно восстанавливает флаги (SPSR->CPSR), например из-за проблем со стеком.

Сообщение отредактировал GetSmart - Nov 23 2009, 15:29

Тяжело дается ассемблер, но вроде как BCS - переход, если больше или равно, т. е. цикл выполнится 1 раз. Иначе вообще бы ничего не работало
Это соответствует исходному коду функции wbCalcDA



Думаю, что это и есть самая вероятная причина. Но, глядя на листинг обработчиков прерываний, ничего подозрительного не нахожу. Правда, смотрел только на использование R8. Все смотреть тяжеловато, проект очень болшьой, а я с ассемблером на "Вы".
fiq в проекте не используется, вложенные прерывания - тоже
IAR показывает, что стеков хватает с запасом. Проверял (считал сам и смотрел на содержимое ОЗУ) - не врет.

Ну я знаю, что 5.30 косячный... Сам на грабли наступал при включении оптимизации: неверное переключение THUMB/ARM.
А толку то возмущаться? Если есть 5.40?
После перехода на него мои грабли исчезли..

Похоже, косяк был связан все-таки не с компилятором. Обнаружилось, что размеры стеков были заданы не кратными 4. Из-за этого в прерываниях указатель стека тоже не был кратен 4. Если команда использовала указатель стека при адресации, 32-битные данные переписывались неправильно. Это сразу выявилось, когда локальные переменные в прерываниях стали типа int. Раньше использовались char и short. Разбираться, чтоб однозначно определиться с причиной, уже некогда. Т. к. в стеке может применяться выравнивание по 8 байт, теперь делаю размеры кратными 8 или 16.

Но вот сегодня столкнулся с другой проблемой - уже в IAR 5.40
Делаем расчет КИХ-фильтра, т. е. считаем свертку буфера сигнала с массивом коэффициентов. Без оптимизации все работает. Делаю оптимизацию High, Speed. Убираю галочки Function inlining и Static clustering. Получаю глюк. Ошибку видно в ассемблерном коде. Исходники на С и ассемблерный код прикладываю.

Суть ошибки в следующем. Буфер входного сигнала - кольцевой. Т. к. фильтр симметричный, умножений можно делать в два раза меньше. При расчете свертки движемся по буферу, используя два индекса, двигающихся в разных направлениях. Длина буфера 256 значений. На индексы надо накладывать маску 0xFF, чтобы "закольцеваться". Я для этого объявил индексы типом unsigned char.
Имеем цикл на С
for (i = 0; i < 128; i++)
{
x = f->buf[k1] + f->buf[k2];
sum += (long long)x*k2120v2[i];
k1++; k2--;
}
И ассемблерный код
// 66 x = f->buf[k1] + f->buf[k2];
// 67 sum += (long long)x*k2120v2[i];
??Lpf2120v2_1:
LDR R5,[LR, #+8]
ADD R6,R2,R3, LSL #+2
LDR R6,[R6, #+8]
ADD R5,R6,R5
LDR R6,[R12], #+4
SMLAL R0,R1,R5,R6
// 68 k1++; k2--;
SUB R3,R3,#+1
AND R3,R3,#0xFF
// 69 }
ADD LR,LR,#+4
SUBS R4,R4,#+1
BNE ??Lpf2120v2_1
в качестве переменной k2 используется R3 и с ним происходит все правильно
k1 в коде нет, вместо этого применяется указатель, который лежит в LR, и вот он-то выходит за пределы буфера и мы имеем глюк

Теперь надо пробовать новую версию IARа? Или сразу другой компилятор?
У нас некоторые разработчики используют Keil. Кто-нибудь про него знает чего-нибудь плохого?

Посмотрел в код - действительно глюк. Причём очень выпуклый: достаточно всего нескольких строчек кода, чтобы его вызвать.
Может быть, совпадение, но после того как я попытался обновить компилятор IAR Coldfire с 1.22 до 1.23, я столкнулся с генерацией некорректного кода. Пришлось откатиться обратно на 1.22. Похоже, что-то у IAR разладилось.
На самом деле от этого ни один компилятор не застрахован. Можно надеяться на популярность компилятора: если много людей используют, то глюков меньше. У Кейла компилятор - RealView от ARM. Кстати, очень популярный компилятор. Я как-то раз столкнулся с генерацией некорректного кода этим компилятором...

Поизучал оптимизацию. Косяк возникает только если выбрана High оптимизация по Speed или Balance независимо от выбора галочек. Сделал High по Size. Все вроде нормально стало. Общая производительность упала процентов на 5-6. Устраивает.