Pull to refresh

Comments 40

Это вторая статья, где я это увидел и в обоих случаях ваш комментарий заминусовали. Задумайтесь
Как вариант попробовать разогнать SWD до максимальных частот и попробовать перехватить управление (остановить программу) до момента когда она стопит тактовые частоты. Или «поиграть» с настройками сброса «connect under reset». Перебрать отладочные шнурки типа Ulink/ULINK-pro/J-link…
Я пробовал только uLink. С ним ничего не получилось. Когда добуду JLink — попробую с ним.
а что пишет Datasheet о режиме OnDemand — каковы условия для входа в него и выхода из него?
каким программатором-отладчиком пользуетесь?
в J-link есть режим Connect under Reset — может это поможет?
У меня сейчас есть только uLink и соответственно uVision. Там перепробовал все режимы — не помогает. Тут же еще SWD. Он не все режимы полноценного JTAG поддерживает.
Для STM32 мне помогло Debug->Connect & Reset Option -> Connect:under Reset Reset:HW RESET
Внешние кварцы не помогают? JTAG или подобное есть?
Кварцы стоят, но они программно отключаются сразу после выполнения пользовательского кода.
еще со студенческих времен меня учили, что «с Atmel работают одни дилетанты»
Дальше можно не читать. Специалисты — такие специалисты!
Неужели у этого МК нет ноги или комбинации для полоног стирания кристалла?
А это что?
http://www.atmel.com/Images/Atmel-42181-SAM-D21_Datasheet.pdf

пункт 13.7
The Chip-Erase operation is triggered by writing a '1' to the Chip-Erase bit in the Control register (CTRL.CE)

Это программный сброс.
Там далее, по ссылке «cold start» можно узнать, что есть, так называемый «CPU reset extension».
После внешнего ресета CPU, если видит отладчик, то сидит и ждет записи бита в спец регистр CSRTEXT.
Пока отладчик этого не сделал, CPU не выйдет из ресета и программа в МК не запустится.

Поэтому копайте в сторону скриптов для вашего отладчика. После подачи ресета и до подачи CSRTEXT можно полностью стереть кристалл. Наверняка к вашей IDE такой скрипт уже прилагается, либо его не сложно написать самому.
Более того, этот CPU reset extension прекрасно описан там же в 13.6.2. Судя по всему, всё, что требуется, — это притянуть SWCLK к земле, пока отпускается ресет. Может, даже никаких скриптов или специальных отладчиков не нужно.
«с Atmel работают одни дилетанты» — плод несозревшего юношеского сознания…
Можно аккуратно вскрыть кристалл и ультрафиолетом засветить ПЗУ, где хранятся настройки.
Ещё из вариантов:
— ултрафиолет+вскрытие = рентген без вскрытия. Или другое ионизирующее излучение достаточной мощности чтобы пройти через корпус
— пощупать его мощным высокочастотным эми
— аккуратно(!) пройтись высоким напряжениям по пинам контроллера (типа електрозажигалки, но на расстоянии, дабы не было пробоя). Это если совсем безнадёга :D — имеется риск сжечь что-то работающее(!)

А по хорошему — успеть программатором, как советовали. У STM32F4 (горький опыт) тоже есть такая фишка, если случается переход в какой-то глубоко спящий режим(точно не вспомню) а доступ только через SWD. Про Hwreset не скажу, т.к. обошлось без него.
Возможно для ATMEL есть ещё какие-то свои отладочные ср-ва
Не знаю в точности, как обстоит с кортексом, но серия mega у Atmel в случае ошибочно прошитого конфига источника тактирования (например вместо кварца выбрали RC-цепочку) тоже не поддается сбросу, если у вас нет программатора с выходом тактирования. При входе в режим программирования mega выбирает в качестве источника тактирования или источник, указанный в настройках кристалла или же тактируется внешним генератором, который входит в состав программатора (особо подчеркну, что не любой программатор имеет выход тактирования. Phyton'оновские имеют точно). Прочитайте внимательно даташит на контроллер, скорее всего его тоже можно сбросить подобным способом.

AVR — это принципиально другая архитектура. Там тестирование задается жёстко фьюзами. У ARM нет фьюзов.

Прошу прощения, мой телефон внёс правки. :)


Не тестирование, а тактирование, конечно. И я не дописал: у ARM нет фьюзов для жёсткого задания тактирования, это делает программный код. Собственно, об этом и речь в статье.

Радиационно стойкие микроконтроллеры от Atmel сейчас очень популярны для малых космических аппаратов, и я бы не сказал что их дилетанты проектируют.
Была аналогичная проблема на Stm32f100 при попытке переносе проекта из Cube'a в кокос, мк тоже не подавал признаков жизни. Из-за того что программатор был от VLdiscovery, не было возможности сделать Connect under Reset, просто потому что у программатора не было этого провода. Решилось так: прижимаем ресет, в утилитке нажимаем full chip erase, отпускаем ресет и мк очищается.
На старых добрых «мегах», всегда можно было воспользоваться HV-программированием и подключить выключенный SPIEN.
> Я пробовал только uLink. С ним ничего не получилось. Когда добуду JLink — попробую с ним.
Мдя. Видимо про OpenOCD, вы ничего не слышали?
Стандартный высоковольтный программатор не? ВСЕ (поправьте если не прав) чипы от атмеля могут прошиваться через 12в программаторы.
Read datashee, Luke!

Стандартный высоковольтный программатор — это для AVR, у ARM по-другому всё, они программируются через SWD. Atmel ≠ AVR.

У ATMEGA похожая фича есть. В фьюзах есть биты, определяющие, откуда тактировать. И среди всех комбинаций есть неиспользуемые. И если таковую туда записать, то получается необратимый кирпич… А еще чтоб положительных эмоций себе добавить, попробуйте обратиться в их техподдержку :)
Не подскажете пример такой комбинации? Сколько я ни издевался над Мегой, пытаясь превратить ее в кирпич, всегда удавалось воскресить МК параллельным программатором (у меня Фитон)
ATMEGA165p, в байте Fuse Low четыре младших бита — CKSEL. По умолчанию там 0010 (внутренний клок), а зарезервированные значения — 0011, 0001, 0101, 0100. Значение 0000 — внешний клок (если записать туда 0000 при отсутствии внешнего клока — тоже весело, но все же решаемо).
Классический вариант — в прошивке переключаемся на внешний кварц, который нераспаян. В поздних ревизиях чипов это исправили — RC генератор продолжает работать на низкой частоте и чип живет, хоть и очень медленно.
У некоторых чипов (например ATmega8) пин RESET совмещен с GPIO и фьюзом можно заблокировать RESET, что делает последовательное программирование и отладку невозможными.
Параллельное программирование спасает только если у вас все нужные пины или свободные, или толерантны к внешним сигналам. Такое в реальных схемах редко встречается — держать 16 пинов в качестве запасных довольно расточительно.
Да, это понятно. Но подразумевалось, очевидно, что кирпичом становится сам МК, то есть никакими манипуляциями его уже не воскресить. А на самом деле имелось в виду, что запаянный МК в smd-корпусе с разъемом для последовательного програмирования становится кирпичом. А так, если корпус DIP(что нередко в любительских конструкциях) — достаем проц из панельки и восстанавливаем заводские настройки фьюзов параллельным программатором. Можно заморочиться и отпаять МК от платы и также воскресить параллельным программатором через специальный переходник(ZIF socket for SMD). Только не уверен, что МК выдержит еще один цикл запайки.
Любительские конструкции и DIP-корпус — это отдельная тема…
В коммерческих же устройствах нет разницы — окирпичился МК или всё устройство, в любом случае — это возврат по гарантии со всеми вытекающими издержками. А если устройство нельзя перепрошить на месте или хотя бы в сервисе — значит, это кирпич. Фьюзы у ATmega пишутся как-то ненадёжно, бывает, что сдвигаются на 1 байт — сталкиваемся с этим даже в производстве. Что уж говорить об удаленном обновлении прошивки — каждый раз стресс. Порядка 80% возвратов по гарантии — сбой фьюзов при обновлении firmware. Дизайн старый, параллельное программирование невозможно, так что чипы выбрасываются и впаиваются новые. Если прибавить сюда так и не исправленный за 15 лет flash (непредсказуемая выносливость по числу перезаписей), то становится понятно, почему у Атмел репутация — «контроллеры для любителей».
Ну так это дело не в контроллере, «проблема с руками». Эдак любой контроллер убить можно. Как в анекдоте: «Один сломал, второй потерял.»
Имеет смысл на этапе отладки поставить после старта задержку на пару сек. чтобы отладчик успел зацепится.

Да контроллер не убит вовсе, а очень даже наоборот. Просто его теперь не запрограммировать, пока он работает. Но для этого и придумали Cold-Plugging (он же "Connection under reset" много раз тут упоминавшийся). Надеюсь, автору это поможет и он добавит в статью историю о решении возникшей проблемы. :)

Имея опыт разработки аппаратных проишивальщиков/загрузчиков могу с большой долей уверенности сказать, что в любом контроллере в режиме Under-reset должен осуществляться опрос портов встроенного дебагера. Дебагер ждет появления определенной входной последовательности на выделенной для этого ноге, при этом тактируется по заводским настройкам. В зависимости от задачи, иногда ведь приходится задействовать и пины отладочного модуля в пользовательском режиме. Причем с конфигурацией через так называемые option-bits, которые загружаются еще до попадания на вектор Reset. Чтоб была возможность перепрошить контроллер каждый производитель просто обязан предусмотреть вход в отладочный режим в состоянии reset'a. Конечно же, если речь не идет об однократно-программируемых. Другое дело, что указанный внутрисхемный отладчик не полностью реализует необходимую последовательность подключения.
Sign up to leave a comment.

Articles