nanorobot 3 29 октября, 2014 Опубликовано 29 октября, 2014 (изменено) · Жалоба Проект был начат в 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. Изменено 29 октября, 2014 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 29 октября, 2014 Опубликовано 29 октября, 2014 · Жалоба Проект был начат в IAR, но по причинам, которые долго объяснять, перешел на GCC. Кстати, Keil умеет отлаживать код, который выдаеёт gcc (правда, gcc 4.7 работает, а вот на gcc 4.8 кейловский отладчик падает). Кейловский отладчик уж поудобнее будет, чем эта кривая эклипса. Выполнение инструкции <LCDx->TIMV = regValue;> (см скриншот) вызывает Target halted отладчика(JLink/SWD). MCU улетает в неизвестное состояние (на HardFault, BusFault и прочие фаулты, поставлены обработчики, выводяшие соотв. сообщение в USART, чего не происходит ) Не мешало бы подойти к точке сбоя в окне дизассемблера, чтобы точно установить, какая инструкция виновата. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 3 29 октября, 2014 Опубликовано 29 октября, 2014 (изменено) · Жалоба Кстати, Keil умеет отлаживать код, который выдаеёт gcc (правда, gcc 4.7 работает, а вот на gcc 4.8 кейловский отладчик падает). Кейловский отладчик уж поудобнее будет, чем эта кривая эклипса. Не мешало бы подойти к точке сбоя в окне дизассемблера, чтобы точно установить, какая инструкция виновата. К своему стыду признаюсь, в ассемблере THUMB слаб. Для АВР - да, использовал. Но здесь непонятное с доступом. На скриншоте 1 дамп памяти, где расположены регистры LCD, до выполнения первого оператора реализующего доступ к этим регистрам. Все они равны 0 кроме регистров палитры(с адреса 0x40008200). На втором скриншоте nот же дам памяти после выполнения оператора. Все регистры недоступны. Блин, пока писал понял, что недоступны не только регистры LCD, но и все прочие - теряется связь МК с JLink. Последняя проверка показала что обращение(запись) к регистру LCDx->UPBASE (адрес фреймбуфера) - к подобной катастрофе не приводит Изменено 29 октября, 2014 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 3 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба Написал минимальный фрагмент, который "весит" CPU. После выполнения оператора в строке 112, процессор впадает в некую кому. Это точно не HardFault или какое либо unhandled_exception. На все обработчики прерываний поставлены заглушки с зажиганием светодиода, и их отработка проверена(на примере HardFault). В зтом состоянии обрывается связь JLink c CPU . Перезапуском GDB сервера связь восстановить не удается, только ресетом (см скриншот 2) . Перезапуск JLink не требуется, то есть виснет именно ядро(CPU) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
lotor 0 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба У Вас в Iar и GCC один и тот же startup код? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 3 30 октября, 2014 Опубликовано 30 октября, 2014 (изменено) · Жалоба У Вас в Iar и GCC один и тот же startup код? Нет, В GCC Statrup от РТОС ChibiOs. Точнее сказать - вместе с ChibiOs Изменено 30 октября, 2014 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 123 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба Может ядро где-то кем-то загоняется в спячку? Гляньте - вроде как был какой-то регистр, который позволял не отключать отладчик при уходе в спячку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 3 30 октября, 2014 Опубликовано 30 октября, 2014 (изменено) · Жалоба Может ядро где-то кем-то загоняется в спячку? Гляньте - вроде как был какой-то регистр, который позволял не отключать отладчик при уходе в спячку. Проект в самом начале, процессов которые могли бы усыпить ядро - нет. Кроме главного процесса есть еще один, мигает ледом - признак контроля жизни. Да и все режимы типа Sleep/Power down запрещены в соотв. регистре. Разрешить работу отладчика во сне/повердовне похоже нельзя. Изменено 30 октября, 2014 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
nanorobot 3 31 октября, 2014 Опубликовано 31 октября, 2014 (изменено) · Жалоба У Вас в Iar и GCC один и тот же startup код? Неожиданно для меня, но причина видимо действительно где то здесь. С целью анализа ситуации перенес существующий зачаток проекта снова в IAR(ранее в IAR было без ChibiOs, и, соответственно, без его startup). Симптомы в IAR ровно те же, что и в GCC ! Ув. Lotor, не продолжите Вашу мысль? Изменено 31 октября, 2014 пользователем nanorobot Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
