Перейти к содержанию
    

Конфликт при обращении к Flash из среды отладки - возможно ли?

Доброе время суток, уважаемые коллеги!

 

Возможно, ранее поднималась похожая тема, но я пока не нашел. Есть миландровский МК 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)?

Изменено пользователем bseyur

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2) Как в теории чтение памяти МК из среды отладки может помешать нормальному выполнению кода (применительно к Cortex-M0)?

Легко может помешать.

Например строка флэш разрядностью 64-128-XYZ бит копируется в буфер откуда выдается процессору по мере обращения. Так могли сделать ради повышения быстродействия, оптимизации размера флэш, оптимизации потребления, да может у них такой готовый блок был а менять лень или нет прав. При чтении отладчиком в буфер попадает другая строка а процессорная шина этого не замечает потому что множественный доступ не предполагался и проверка актуальности данных в буфере не выполняется.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) Можно ли "прописать" отечественные МК в базу j-link, и вообще, насколько это важно для отладки?

Можно, на форуме Миландра и в доках от Segger есть описание, как это делается. Для отладки это вообще не важно, поскольку J-link работает со стандартным ядром.

Вопрос: Сбои наблюдаются на любой частоте работы МК или только после "разгона" PLL?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо, посмотрю! Вообще пробовал на разных частотах, сейчас стоит кварц на 8 МГц без PLL.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

на 8МГц не должно сбоить. ВЕ91 на 80 МГц иногда так же тупит, но в основном с перефирией. Область кода обычно не смотрю - нет необходимости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...