Сегодня удалось-таки проверить в приборе прошивку, скомпилированную новой версией 4.10A. Работает!
Оптимизация High-Balanсed, опция Code motion по традиции выключена. Reduce stack usage включена.

В 3.42a с такими же установками (только оптимизация High-Speed) было

Куда в 4.10a деваются константы, не пойму до сих пор

Кстати, я ручками посчитал по всем файлам *.lst сколько констант используется, и сравнил сколько пишет в конце и 3.30а и 4.10а.
В *.lst - количество const одинаковое в обоих версиях, и оно больше, чем то, которое написано в конце, после линковки. В обоих версиях "результат" меньше "суммы", в 4.10а просто он меньше, чем в 3.30а.
У меня, кстати, надурняка с 3.30а на 4.10а перекомпилировалось без ошибок, не заработало, но сейчас "переправа" сразу нескольких проектов, притормозил переход... хотя попробовать охота...

Чем вызвана такая такая нелюбовь к Code motion ?

По поводу констант сложидось впечатление что он их начал активнее инлайнить. Сравнить уже не с чем моcты сожжены

Глючит. У меня переменную, которая менялась в цикле, выводила за цикл...
Где-то здесь писалось.

Исторически так сложилось. Глючит эта опция у IAR. IAR даже с volatile не всегда корректно обходится

1 ) В одном проекте только часовой кварц, контроль которого встроенными средствами MSP не поддерживается. Поэтому было сделано грубое сравнение таймера от кварца с программным циклом от DCO. Цикл изменился, константу пришлось менять.

2 ) Ага, я его сломал! Поставил оптимизацию high, balanced, снял галку Code motion.



3) Поигрался с галками. Ошибка исчезает, если снять галку Function inlining. То есть функция "проинлайнена", а линковщик ищет указатель на нее и естественно не находит.

Вывод: реальный глюк, однако...

Угу. Function inlining чаще всего тоже убираю. Особенно когда в программе много работы с указателями.

Оказывается, у меня принудительно стояла "pragma inline" для этой функции.
Видимо, отследить человеческим разумом сочетания возможностей среды и компилятора просто нереально.

Если придерживаться правила "буть проще", видимо многих косяков можно избежать.

А еще в новой версии происходит контроль заполнения стека. Если на момент останова стек занят более чем на 90%, в окне сообщений выводится предупреждение.
Правда, над выбором точки останова нужно подумать самому. А при наличии вложенных прерываний вряд ли вообще можно поймать такую ситуацию.

В 3.42А это уже было и настраивается в опциях отладчика. При отладке в операционке вообще вещь бесполезная, т.к. стек там всегда не "там". А у меня и в main пишет что стек кончился Так как в качестве стека main используются буфферы таск, которые до старта таск не нужны.

Такая проблема.
У меня в Симуляторе IAR for MSP 4.10 подпрограмма длительностью примерно 1 млн. циклов выполняется порядка 1 минуты. Это при условии, что активно окно IDE, иначе еще дольше.
Вопрос: Что симулирует Pentium целую минуту в процедуре, котрую MSP должен исполнить за 125мс?
Как уменьшить это время? Может в настройках что-то не то?

Проверить на старых версиях IAR for MSP сейчас нет возможности, но я запихнул ту же процедуру в IAR for AVR - там симуляция занимает несколько секунд, что вполне приемлимо.

Вот проверил скорость выполнения процедуры БПФ в разных версиях симулятора IAR EW430:
3.21 31 сек
3.40 55 сек
3.42 52 сек
4.10 60 сек
IAR AVR 4.20 3 сек !!!!!
Особенно удивила старая 3.21 - работает быстрее новых.
Напоминаю - число циклов процессора MSP430 в данной процедуре порядка 1млн.
Кто-нибудь сталкивался с такой ситуацией?

ИМХО это особенности симуляции Фон-Неймановской архитектуры у MSP430, в отличие от Гарвардской у AVR.

Наступил на грабли при вызове ассемблерных процедур!

Соответствие параметров и регистров изменилось!!!

См. стр.93 "EW430_CompilerReference.pdf", правьте свои исходники на ассемблере, во всяком случае те, у кого в вызываемых функциях более одной переменной.