Устройство STM32F7 зависает: нет доступа к регистрам

Если отладчик заблокирован, при условии, что питание/тактирование в порядке, то наиболее вероятным результатом будет внутренняя взаимоблокировка шины. Например, если у вас есть внешняя XIP EEPROM и вы неправильно настроили устройство, периферийное устройство может зависнуть, когда вы нажмете определенные шаблоны адреса/данных.

Вы все еще можете прочитать информацию об ОЗУ после сброса (или добавить некоторую трассировку, чтобы сбросить что-то в ОЗУ). Базовые архитектурные регистры не сбрасываются (если у вас нет части, относящейся к безопасности с высокой надежностью), поэтому, если вы поместите a B selfв обработчик сброса (при условии, что отладчик «остановка после сброса» не работает), тогда ваше старое состояние должно быть сохранено .

Вы можете использовать трассировку ETM для захвата трассировки в реальном времени, и если вы записываете трассировку в ETB, вы можете просто прочитать ее после сброса (опять же, она должна быть постоянной) без использования зонда (но, возможно, указатель буфера будет потерян, поэтому вы может потребоваться ручная обработка трассировки). Трассировка ETM покажет ветки (адреса для любой непрямой ветки) и исключения (включая блокировку), поэтому вы должны получить достаточно точное представление о том, что было последним. В частности, трассировка просто «наблюдает» за ядром, поэтому она видит, что инструкции удаляются, не подвергаясь влиянию активности шины. DWT также может дать что-то полезное - в зависимости от того, что на самом деле не работает.

Как указано в одном из комментариев, по крайней мере, используя MDK, вы можете подключиться к «горячей» работающей цели (без сброса/остановки, без загрузки кода), поскольку порт отладки представляет собой полностью асинхронный мастер шины, встроенный в ядро . Это дает вам возможность исследовать состояние памяти устройства с длительным временем безотказной работы (но не основных регистров) с минимальным вмешательством, и это может быть полезно для подтверждения диагноза. Вы даже можете написать регулярный опрос ячеек памяти, если это актуально.

Наконец, поскольку порт отладки «действует как ядро», вы можете имитировать довольно много сбоев взаимных блокировок шины, просто используя окно памяти отладчика.

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

1. Проблема может заключаться в коротком замыкании где-то на плате или в разомкнутом соединении, или, возможно, в слабом соединении. Мы не знаем, что это может быть. Итак, прежде всего, очистите всю плату изопропиловым спиртом (он же очиститель печатных плат), хорошенько потрите ее зубной щеткой, а затем используйте Kimwipes, чтобы вытереть грязь/пыль/металлические частицы и т. д. Проверьте, работает ли UC. Если это не так, осмотрите послеочистку печатной платы на наличие оборванных дорожек, поврежденных контактных площадок печатной платы, соединений холодной пайки и т. д. На этом этапе желательно попробовать переработать всю плату, чтобы устранить проблему «ослабленных соединений/стыков». Проверьте, работает ли UC после этого.

2. Если UC по-прежнему не работает, проверьте основные факторы, такие как колебания напряжения питания, шумы в сигнальных линиях, тактовые импульсы UC и т. д. Используйте DSO для контроля тактовых импульсов и линии сброса. Также проверьте целостность всех разъемов. Пошевелите провода, когда UC работает, и посмотрите, устранена ли проблема. Проверьте эти вещи, а затем снова попробуйте на UC.

3. Если это не решит проблему, проверьте программное обеспечение. Прошить код на новом UC (не на новой макетной плате!). Создайте свою собственную доску разработки barebones. Под barebone-системами я подразумеваю отсутствие подключенных периферийных устройств и внешних схем. Просто часы и несколько регуляторов, вот и все! Вы должны убедиться, что код не замораживает UC. Устранение внешних периферийных устройств устранит проблемы, связанные с ними (если таковые имеются). Итак, теперь это проверяет ваше программное обеспечение. Когда вы делаете свою собственную плату разработки barebones, замигайте светодиодным кодом, чтобы убедиться, что она работает. Затем прошейте свое программное обеспечение на UC и проверьте, зависает ли UC или нет. Если это так, то радуйтесь, это было программное обеспечение, вызывающее проблемы. Внесите необходимые изменения в программное обеспечение и заставьте его работать на базовой плате разработки. Как только он отлично заработает на bb devboard,

4. Если UC все еще зависает, это означает, что вы, возможно, изменили некоторые биты регистра UC, которые нельзя трогать, с помощью программного обеспечения. Проверьте свое программное обеспечение и запишите все регистры и биты, которые оно изменяет. Убедитесь, что программное обеспечение безопасно использует UC.

5. Если проблема не устранена, проверьте, правильно ли работает используемый вами флэш-инструмент. Сделайте это, используя флеш-инструмент для отладки «здоровых» плат UC. Если операция прошла успешно, то ваш flash tool в порядке.

6. Если ваше программное обеспечение зависает каждый UC, то, вероятно, это проблема с программным обеспечением. Проверьте, есть ли в STMm32F7 что-то вроде «Используйте параллельный программатор высокого напряжения для сброса фьюз-битов». Блокированные микроконтроллеры Atmel можно восстановить с помощью HVPP.

Попробуйте эти методы и дайте мне знать, что происходит. Будьте терпеливы в процессе отладки, устраняйте проблемы одну за другой. Помните, программирование — это навык, а отладка — это искусство!