Как отлаживать неожиданные сбрасывания на устройстве STM32?

Question

Я занимаюсь разработкой на C с чипом STM32F107, и в какой-то момент устройство стало перезагружаться, когда я вызываю определенную функцию. У меня нет отладчика, и моя отладка - это просто текст через последовательный порт.

Я использовал некоторые другие микроконтроллеры, в которых я смог получить доступ к регистру, чтобы увидеть причину сброса, но я не могу найти эквивалент для этого устройства. Я знаю об аппаратных исключениях Cortex-M3, но я не знаю, запускается ли один из них, поскольку я не могу отправить текст поверх usart, когда я внутри этих обработчиков (возможно, потому, что мой TX функции используют прерывания?).

Итак, я решил попросить людей с большим опытом, чем я в этом устройстве: что обычно делается для отладки таких ситуаций?

EDIT

Один из разработчиков активировали сторожевой WWDG и это сброс оборудования, прежде чем я мог бы получить мою информацию от обработчиков сбоев. Это был Hard Fault из-за вызова функции указателем, который указывал на неправильное место. Тем не менее, я буду держать этот вопрос в надежде, что кто-то даст более подробную информацию (или материал об этом), чтобы указать на код C из регистров, сохраненных в, скажем, Hard Fault (идея @dwelch).

Answer 1

Cortex M3 обладает отличными функциями обработки ошибок, которые облегчат вашу жизнь. При попадании на ошибку он автоматически складывает несколько регистров, таких как ПК и LR, а регистры состояния неисправности будут сообщать вам такие вещи, как адрес ошибки шины и т. Д.

Вы должны реализовать хороший обработчик ошибок (например, жесткий обработчик ошибок здесь: http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/), чтобы распечатать сложенные регистры и регистры регистрации ошибок отладки.

Вы должны использовать UART для печати, просто напишите свою собственную пользовательскую версию printf для использования с обработчиком ошибок, которая не зависит от прерываний. Просто напишите байты непосредственно в регистр данных uart Tx и опрос для завершения байта.

Answer 2

Учитывая, что у вас нет отладчика, я бы посоветовал вам найти на периферии микроконтроллер, чтобы помочь вам. Возможно, у вас есть светодиод, который вы можете переключить, или простой контакт GPIO, который не используется, который вы можете подключить к осциллографу. Если вы медленно переключаете контакт GPIO (не более 1 Гц и, возможно, медленнее в зависимости от счетчика), вы можете использовать вольтметр вместо области. Поместите код для переключения светодиода или вывода GPIO в каждом из обработчиков исключений по одному, пока вы не отследите его. Если у вас имеется более одного штыря GPIO, вы можете ускорить процесс. Вы также можете написать оболочку для конкретной функции, вызывающей сброс. Функция-оболочка отправляет список прерываний, которые активируются непосредственно перед выполнением функции разбиения. Таким образом, вам не нужно тратить время на тестирование тех, которые не включены.

Одно из преимуществ контактов GPIO в этом случае - это не требует прерывания. Лучше избегать всего, что требует прерывания (например, ваш USART в этом случае). Если сброс вызван более высоким приоритетом, ваш код отладки никогда не будет выполнен.

Также распространено, что сброс вызван неинициализированным указателем. Указатель функции, установленный на ноль, заставит выполнение выглядеть так же, как сброс. Если это так, код инициализации USART, вероятно, выполняется до того, как байт может быть полностью передан USART, который сделает этот USART бесполезным в качестве инструмента отладки в этом случае.

Answer 3

Когда вы произносите сброс, я думаю, что вы попадаете в вектор сброса, а не из одного из прерываний или обработчиков.Вы говорите, что он действительно перезагружает чип и снова запускает ваше программное обеспечение, или вы говорите, что он где-то висит? или у вас есть векторная таблица, все точки на векторе сброса?

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

Обычно я сопоставляю неиспользуемые векторы с простой вехой строки кода, которая ведется к себе. Позже я могу переназначить некоторые из них на реальный код.

cortex-m очень приятно, что вы можете указать код C. Если вы считаете, что получаете исключение, укажите, что оно указывает на рутину, которая захватывает что-то, что поможет вам понять, в каком режиме вы находитесь, в реестре ссылок может быть такая информация или где-то csr, распечатать это и перейти в бесконечный цикл , Заполните неиспользуемые части векторной таблицы адресом этой общей функции отладки.

Оттуда вам нужно выяснить, почему вы попадаете в это исключение, это может быть что-то вроде несвязанного доступа, например. Возможно, вы создали прерывание при попытке инициализировать устройство, прежде чем полностью настроить обработчик, который знает.

отредактируйте ваш вопрос с помощью большего количества ответов или информации при работе с этим.

Answer 4

«Правильная» вещь, к сожалению, не практична с STM32. Это будет заключаться в обработчике большого исключения, который знает исходный код и может размотать стек и дать вам полный стек вызовов и номер строки, которые вызывают ошибку. Это потребует добавления всей отладочной информации из вашего приложения во флэш-память STM32, и это нецелесообразно.

Есть способы обмануть вашу среду IDE, чтобы иногда дать вам стек вызовов. Я бы дал подробности, но я забыл записать их, поэтому я забыл. Я думаю, что он должен вручную изменить указатель стека из одного теневого регистра в другой.

То, что я обычно делаю, это поставить точку останова на вектор исключения жестких ошибок, а затем просмотреть все регистры, когда точка перерыва попадает. Рассмотрите их судебные доказательства от убийства, совершенные с использованием пластиковых взрывчатых веществ. Значения регистров дадут вам идеи. Значения регистра, начинающиеся с 0x20000000, - это адреса ОЗУ. Значения регистра, начинающиеся с 0x08000000, - это адреса Flash. Откройте дизассемблер и введите эти адреса. Вероятно, это будет прямо на переменную или функцию в этих местах памяти. Если это не поможет, посмотрите на указатель стека. Посмотрите на ячейки памяти в указателе стека и выполните тот же трюк. Я всегда нашел достаточно осколков для определения местоположения функции, где происходило исключение.

Answer 5

Кроме того, что упоминалось о обработчиках прерываний для отладки, некоторые микрофоны ST также имеют регистр источника сброса, который вы можете прочитать при включении питания (то есть после сброса). Для семейства коры M (m0/m3/m4) регистр RCC_CSR. http://www.st.com/web/en/resource/technical/document/reference_manual/DM00031020.pdf

К сожалению, вы не смогли бы узнать, были ли такие особенности, как жесткая ошибка, но это скажет вам, сработал ли сторожевой таймер (окно или независимый).