LPC4357 Eclipse/GCC, проблема с инициализацией LCD интерфейса Опции

[nanorobot]

Проект был начат в 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.

Сообщение отредактировал nanorobot - Oct 29 2014, 08:14

Эскизы прикрепленных изображений

 

[scifi]

Проект был начат в IAR, но по причинам, которые долго объяснять, перешел на GCC.

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

Выполнение инструкции <LCDx->TIMV = regValue;>
(см скриншот) вызывает Target halted отладчика(JLink/SWD). MCU улетает в неизвестное состояние (на HardFault, BusFault и прочие фаулты, поставлены обработчики, выводяшие соотв. сообщение в USART, чего не происходит )

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

[nanorobot]

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


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

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

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

Сообщение отредактировал nanorobot - Oct 29 2014, 13:04

Эскизы прикрепленных изображений

 

[nanorobot]

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

Эскизы прикрепленных изображений