Проект был начат в IAR, но по причинам, которые долго объяснять, перешел на GCC. В IAR была написана и отлажена инициализация SDRAM и LCD.
При переходе на GCC процедура инициализации SDRAM была отлажена быстро, запуск инициализации LCD вызвал проблемы, которые не могу осознать несколько дней. Как в IAR, так и в GCC используются библиотеки от NXP. Выполнение инструкции <LCDx->TIMV = regValue;>
(см скриншот) вызывает Target halted отладчика(JLink/SWD). MCU улетает в неизвестное состояние (на HardFault, BusFault и прочие фаулты, поставлены обработчики, выводяшие соотв. сообщение в USART, чего не происходит )
Кроме того, после первой записи в регистры LCDx->CTRL &= ~CLCDC_LCDCTRL_ENABLE, JLink пишет в логе: WARNING: Failed to read memory @ address 0x400080xx, так же и эклипса: Cannot access memory at address 0x400080xx, для всех xx адресов регистров LCD.

Кстати, Keil умеет отлаживать код, который выдаеёт gcc (правда, gcc 4.7 работает, а вот на gcc 4.8 кейловский отладчик падает). Кейловский отладчик уж поудобнее будет, чем эта кривая эклипса.


Не мешало бы подойти к точке сбоя в окне дизассемблера, чтобы точно установить, какая инструкция виновата.

К своему стыду признаюсь, в ассемблере THUMB слаб. Для АВР - да, использовал. Но здесь непонятное с доступом. На скриншоте 1 дамп памяти, где расположены регистры LCD, до выполнения первого оператора реализующего доступ к этим регистрам. Все они равны 0 кроме регистров палитры(с адреса 0x40008200). На втором скриншоте nот же дам памяти после выполнения оператора. Все регистры недоступны. Блин, пока писал понял, что недоступны не только регистры LCD, но и все прочие - теряется связь МК с JLink.

Последняя проверка показала что обращение(запись) к регистру LCDx->UPBASE (адрес фреймбуфера) - к подобной катастрофе не приводит

Написал минимальный фрагмент, который "весит" CPU. После выполнения оператора в строке 112, процессор впадает в некую кому.
Это точно не HardFault или какое либо unhandled_exception. На все обработчики прерываний поставлены заглушки с зажиганием светодиода, и их отработка проверена(на примере HardFault). В зтом состоянии обрывается связь JLink c CPU . Перезапуском GDB сервера связь восстановить не удается, только ресетом (см скриншот 2) . Перезапуск JLink не требуется, то есть виснет именно ядро(CPU)

У Вас в Iar и GCC один и тот же startup код?

Нет, В GCC Statrup от РТОС ChibiOs.
Точнее сказать - вместе с ChibiOs

Может ядро где-то кем-то загоняется в спячку?
Гляньте - вроде как был какой-то регистр, который позволял не отключать отладчик при уходе в спячку.

Проект в самом начале, процессов которые могли бы усыпить ядро - нет. Кроме главного процесса есть еще один, мигает ледом - признак контроля жизни. Да и все режимы типа Sleep/Power down запрещены в соотв. регистре.
Разрешить работу отладчика во сне/повердовне похоже нельзя.

Неожиданно для меня, но причина видимо действительно где то здесь. С целью анализа ситуации перенес существующий зачаток проекта снова в IAR(ранее в IAR было без ChibiOs, и, соответственно, без его startup).
Симптомы в IAR ровно те же, что и в GCC ! Ув. Lotor, не продолжите Вашу мысль?