IAR ARM C 4.20a - bug Опции

[Andy Mozzhevilov]

Потратил день времени на вылавливание следующего бага:

short mamont[128];
char slon1;
char slon2;

void mamont_init(void)
{
mamont[0] = 1;
slon1 = 0;
slon2 = 0;
}
\ mamont:
\ 00000000 DS8 256
2 char slon1;
\ slon1:
\ 00000100 DS8 1
3 char slon2;
\ slon2:
\ 00000101 DS8 1
4
...
5 void mamont_init(void)
6 {
7 mamont[0] = 1;
\ ??mamont_init:
\ 00000000 10009FE5 LDR R0,??mamont_init_1 ;; mamont
\ 00000004 0110A0E3 MOV R1,#+0x1
\ 00000008 B010C0E1 STRH R1,[R0, #+0]
8 slon1 = 0;
\ 0000000C 0010A0E3 MOV R1,#+0x0
\ 00000010 B010C0E1 STRH R1,[R0, #+256]
9 slon2 = 0;

slon1 и slon2 располагаются в памяти рядом. Компилятор, начиная с уровня оптимизации 6, считает, что раздельное обнуление этих переменных через STRB можно соптимизировать в одно обращение через STRH сразу для обеих переменных. При этом несколько забывая, что для STRH максимальный оффсет задается 8 битами и не может превышать 255. Баг проявляется, если нужно смещение 256,
если оффсет нужен больше, то там все нормально. В 4.11a этого бага нет.
regexp для поиска этого бага в lst файлах :
STRH R.+,\[R.+, #\+256\]

[Muxa]

Друзья. раз уж разговор о версии 4.30A
мне показалось, что есть баг в обработке FIQ
несмотря на модификаторы __fiq __arm void fiq_handler( bla-bla-bla...
он упорно генерит код для регистров irq, а не fiq
в моем случае в теле обработчика изменялся r8, а не r8fiq
времени было мало. я так и не понял, кто глючит, c-spay или сам компилятор

короче, FIQ я так и не запустил... ограничился векторными IRQ

кто сталкивался?

[Andrey_Sudnov]

Друзья. раз уж разговор о версии 4.30A
мне показалось, что есть баг в обработке FIQ
несмотря на модификаторы __fiq __arm void fiq_handler( bla-bla-bla...
он упорно генерит код для регистров irq, а не fiq
в моем случае в теле обработчика изменялся r8, а не r8fiq
времени было мало. я так и не понял, кто глючит, c-spay или сам компилятор

короче, FIQ я так и не запустил... ограничился векторными IRQ

кто сталкивался?

Может я ошибаюсь, но мне кажется, что компилятор тут не причем. То, будут ли использоваться FIQ регистры, зависит от источника прерывания - FIQ или IRQ.
Другой вариант, что в низкоуровневом обработчике прерываний меняется mode на User/Svc, чтоб пользоваться обычным стеком, так как FIQ очень мал (12 байт).
Посмотрел у себя, да, в стандартном Cstartup.s79 есть:

FIQ_Handler_Entry:
;- Switch in SVC/User Mode to allow User Stack access for C code
; because the FIQ is not yet acknowledged

Вообще, советую FIQ обработчики писать на ассемблере. Иначе толку от них никакого.

[Muxa]

Друзья. раз уж разговор о версии 4.30A
мне показалось, что есть баг в обработке FIQ
несмотря на модификаторы __fiq __arm void fiq_handler( bla-bla-bla...
он упорно генерит код для регистров irq, а не fiq
в моем случае в теле обработчика изменялся r8, а не r8fiq
времени было мало. я так и не понял, кто глючит, c-spay или сам компилятор

короче, FIQ я так и не запустил... ограничился векторными IRQ

кто сталкивался?

Может я ошибаюсь, но мне кажется, что компилятор тут не причем. То, будут ли использоваться FIQ регистры, зависит от источника прерывания - FIQ или IRQ.
Другой вариант, что в низкоуровневом обработчике прерываний меняется mode на User/Svc, чтоб пользоваться обычным стеком, так как FIQ очень мал (12 байт).
Посмотрел у себя, да, в стандартном Cstartup.s79 есть:

FIQ_Handler_Entry:
;- Switch in SVC/User Mode to allow User Stack access for C code
; because the FIQ is not yet acknowledged

с этим всё в порядке.. я попадаю в обработчик FIQ по исключению 0x1C. в регистре VIC состояние фаст интеррапт. в слове состояния проца тоже. стек, ежу понятно, надо определить в *.xlc. в стандартном файле его вообще нет. .. со стартапом порядок, стек выделен и в r13 загружен, а больше ничего и не требуется

подозрения в 2х местах.
- в начале обработчика групповой push в списке которого, в частности r8 и r12. зачем? зачем тогда FIQ с его регистрами.
- в теле обработчика модифицируется r8. когда выполняется эта строка, то c-cpy отображает изменение r8, а не r8fiq. если я руками записываю тоже значение в r8fiq, то программа отрабатывает правильно...

я подозреваю всё же сам генератор кода... если я выключаю отладку и вписываю релиз во флешь, то с помощью JTAG точки останова я попадаю в обработчик по исключению 0x1C, но код работает ровно так же...

Вообще, советую FIQ обработчики писать на ассемблере. Иначе толку от них никакого.

ассемблер ...
гы, - начальство не поймёт... сразу может не уволят, но ...

знашь, всё же посмотрю стартап на досуге, для себя... чёто засело как гвоздь в ботинке
спасибо!

[Ёрген]

Re: в начале обработчика групповой push в списке которого, в частности r8 и r12. зачем? зачем тогда FIQ с его регистрами.

Про эту фичу IARа была тема, автор писал, что написал "bug report", на что ему ответили: "приняли к сведению".

ЗЫ: Это не глюк, это фича. © народное.

[Muxa]

Re: в начале обработчика групповой push в списке которого, в частности r8 и r12. зачем? зачем тогда FIQ с его регистрами.

Про эту фичу IARа была тема, автор писал, что написал "bug report", на что ему ответили: "приняли к сведению".

ЗЫ: Это не глюк, это фича. © народное.

Спасибо! вы меня успокоили...

гы,- насчёт фич...
сорри офтопик, но может кому пригодИтся
в текущем проекте я использую модемный чип подключённый к LPC2129 по SPI. смотрю описание. сигнал slave select, только ввод используется только в слйв мод. в мастер мод вы должны использавать возможности GPIO. ну замечательно. подключаю 3 ноги к модулю spi. ногу ss к gpio. бьюсь где-то 3 часа,- spi не работает. т. е. вообще... лезу в группу на яху. поиск даёт 200 или 300 совпадений,- у многих те-же грабли. наконец нахожу коммент филипса... примерно такой. у нашего проц-а имеется особенность в работе блока spi. бла- бла-бла... у вас нет другой возможности запуска мастер мод, как подпереть вывод ss с помощью пулап резистора к питанию, а для выборки ведомого использовать любой другой свободный пин в режиме gpio. ха-ха, забыли в пин селекшен блоке эту линию
вот и вся фича
з.ы. пулап резистор обязателен!