bseyur 0 2 декабря, 2016 Опубликовано 2 декабря, 2016 (изменено) · Жалоба Доброе время суток, уважаемые коллеги! Возможно, ранее поднималась похожая тема, но я пока не нашел. Есть миландровский МК 1986ВЕ4 с ядром Cortex-M0, у которого под отладкой наблюдаются проблемы. В общем-то не критичные, с такими можно жить, но поведение весьма интересное... Суть в том, что во время выполнения программы среда отладки не должна обращаться к ячейкам flash, иначе следует сбой. К примеру, в ЯРе запускаем режим отладки. Среда нормально подключается к камню по SWD. Далее открываем окна Disassembly и Memory, где показывается содержимое flash-памяти. Выполнение программы НЕ останавливаем. В итоге получаем следующее: 1) При пролистывании содержимого окна Memory в некоторых ячейках Flash отображается "мусор". Но если остановить программу на брейкпоинте, то все нормально. 2) Сразу после сброса МК программа должна делать проверку контрольной суммы содержимого flash. При запуске в таком режиме проверка не проходит. Надо полагать, ядро тоже не может нормально прочесть содержимое Flash. 3) Иногда ядро падает в HardFault на инструкции доступа к flash (в самом коде ничего криминального) 4) Попытки доступа к RAM из среды отладки не приводят к вышеописанным проблемам. Техподдержка Миландра открестилась от этой проблемы и ссылается на некие настройки среды отладки. И действительно, j-link ничего не знает об этом МК, кроме того, что это Cortex-M0, но в дебаггер IAR конфигурация МК загружена! Из доступных настроек есть только уставка скорости обмена, и ее занижение не дало результата. В связи с этим возникают вопросы: 1) Можно ли "прописать" отечественные МК в базу j-link, и вообще, насколько это важно для отладки? 2) Как в теории чтение памяти МК из среды отладки может помешать нормальному выполнению кода (применительно к Cortex-M0)? Изменено 2 декабря, 2016 пользователем bseyur Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_3m 5 2 декабря, 2016 Опубликовано 2 декабря, 2016 · Жалоба 2) Как в теории чтение памяти МК из среды отладки может помешать нормальному выполнению кода (применительно к Cortex-M0)? Легко может помешать. Например строка флэш разрядностью 64-128-XYZ бит копируется в буфер откуда выдается процессору по мере обращения. Так могли сделать ради повышения быстродействия, оптимизации размера флэш, оптимизации потребления, да может у них такой готовый блок был а менять лень или нет прав. При чтении отладчиком в буфер попадает другая строка а процессорная шина этого не замечает потому что множественный доступ не предполагался и проверка актуальности данных в буфере не выполняется. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 2 декабря, 2016 Опубликовано 2 декабря, 2016 · Жалоба 1) Можно ли "прописать" отечественные МК в базу j-link, и вообще, насколько это важно для отладки? Можно, на форуме Миландра и в доках от Segger есть описание, как это делается. Для отладки это вообще не важно, поскольку J-link работает со стандартным ядром. Вопрос: Сбои наблюдаются на любой частоте работы МК или только после "разгона" PLL? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bseyur 0 2 декабря, 2016 Опубликовано 2 декабря, 2016 · Жалоба Спасибо, посмотрю! Вообще пробовал на разных частотах, сейчас стоит кварц на 8 МГц без PLL. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Edit2007 3 2 декабря, 2016 Опубликовано 2 декабря, 2016 · Жалоба на 8МГц не должно сбоить. ВЕ91 на 80 МГц иногда так же тупит, но в основном с перефирией. Область кода обычно не смотрю - нет необходимости. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться