Цитата(ViKo @ Mar 17 2014, 10:04)
...в процессе отладки с помощью ST-Link на Discovery...
а у них достаточное глюкало. что замечено...(тут правда не про кейло примеры, но думаю может пригодится инфа)
1) т.к. бряки пишутся и контролируются в самом STM32 то при сбое в момент отладки может наблюдаться такой глюк в последствии: останов на
пустом месте, где ранее был бряк. И не останов на новых бряках. Лечится снятием питания с таргет микроконтроллера.
2) не совсем точно (т.к. из под виртуалки), но иногда отваливается SWO трэйсер и перестаёт работать ранее отлаженный код (до конца не поймал за
причинное место, но очень большие подозрения на подсистему тактирования-синхронизации). при этом глюк привязан к конкретному одному(!)
проекту-студии. рядом запущенный проект по той же тематике работает на ура. стоит перегрузить весь комп - проблема сама(!) исчезает. встречал
один раз - посему инфа не совсем на 100%
3) на процесс отладки сильно влияют отключение нагрузки (нагревательный прибор) в непосредственной близости. мощность прибора не большая.
отладка JTAG-swd. проявляется как полная потеря контроля над отладкой, так и частичной (трэйс идёт, но любое манипулирование с проектом
вызывает ошибку отладки и как следствие выход из неё). Проблема проявляется на ST-Linke. На отладчиках типа FlashJTAG проблем не замечено
(хотя может и просмотрел момент).
4) IAR иногда ловит глюки при быстрой манипуляции вьюшками. вплоть до падежа программы. Сам IAR ведёт очень большой интенсивный обмен
с файловой подсистемой - посему на расшаренных дисках падает достаточно часто. похоже сохраняет частенько состояние и строит карту для
поиска используемых типов (именно эти действия вызывают прирост юзанья общей памяти этой программкой. если на уровне хэйлохты
мир - проблем нет).
5) IAR+STM32 плохо реагируют на слишком большое кол-во бряков (>4). Если максимаьное кол-во контролируется при запуске отладки, то в процесе
самой отладки можно поставить и больше, но общее поведеия отладчика тогда становится не предсказуемо.
6) IAR+STM32. Плохо дебажится ситуация с кейсами. Сам компилятор вставляет(возможно оптимизация, но другого не видел) обычные сравнения
по каждому случаю, вместо честного кейса. Соответственно дебажный такт перехода на нужный кейс составляет тупой перебор всех кейсов что
написаны выше по коду. По интенсивности светодиода отладчика видно как происходит перебор всех вариант что выше. Соответственно
лучше использовать конкретный бряк на конкретном кейсе - время отладки сокращается.
ик...
Сообщение отредактировал kolobok0 - Mar 17 2014, 10:46
Keil, ST-Link, error 57
Mar 17 2014, 06:04
