Сегодня принесли МТ-линк, подключил, запустил пробную прогу в ИАРе с AT91SAM7X256-EK. ИАР пишет unable halt core. Как победить?

Хм.
Перед тем как дать ответ , задам ряд вопросов :
1) чем шьетесь ? (программатор МТ-линк - если можно ссылочку)
2) правильно ли выбран программатор в самом ИАРе?
3) верный ли драйвер программатора (возможно нужен RDI драйвер)?
4) возможно глюканул иар ( у меня такое бывало, перезапуск ИАРа помогает )

Если для прошивки используется Segger AT91SAM-ICE, то возможно следующее :
1) непропай или микротрещина дорожки с разьема программатора.
2) повреждение самого шлейфа.
3) глюки самого программатора.
4) Глюки ПО.

Больше деталей - попробуем разобратся...

Уважаемые коллеги! У меня такая же проблема, когда принесли свежую плату, сначало заработало на ура, прошло две недели, так компилятор ИАР стал ругаться на Unable halt ARM core, перепаяли проц, снова заработало опять на две недельки, хочу разобраться откуда и по возможным каким причинам возникают эти сообщения? Благодарен за любой ответ

Это глюки атмела. У процессоров очень нестабильный jtag интерфейс. Раньше грешил на различные переходники, но без них( с отладочной 4-х слойной платой и стандартным 20-пиновым разъемом) картина та же самая.

Видимо когда в проц уже загружена программа вся прериферия и ядро не всегда могут остановиться. Полное стирание кристалла перед прошивкой помогает. Учтите однако что стирание через j-flash тоже проходит не с первого раза. Если ничего не помогает - последнее средство ножка Erase.

Так же учтите что у процов очень чувствительный к статике генератор - можете вывести проц из строя "ни с того ни с сего".

Удачи.

Да что вы такое говорите? Уж с чем с чем, а со стабильностью JTAG интерфейса к Atmel'у нареканий нет. Много шустрее и прогнозируемее чем NXP..
Может быть вы просто не учитываете на какой частоте работает core?

Лекарство тут такое - в настройках RDI (если драйвер старый) обязательно точно указать тип процессора и точно указать частоту на котором работает ядро. Причем частота эта должна быть установлена не на глаз и не потому что у вас в программе устанавливается такая частота, а
по критерию реальной частоты проца, для ее определения можно воспользоваться утилитов J-Link Commander
> testcspeed 0x200000

Если драйвер новый (3.80 и выше) где автоопределение частоты ядра, там только играть со скоростью JTAG клока.

Надо помнить что от частоты ядра зависит:
1. Тайминги записи во флеш.
2. Максимальный битрейт JTAG интерфейса.


Такое впечатление что вы даже не пытались разобраться от чего у вас глюки.

Главное это помнить, что проц стартует на внутреннем RC - 32Khz. И если программа зашитая в чип не переключает или не может переключить клок на Crystal / PLL, то проц будет работать совсем не на ожидаемой частоте. Поэтому еще раз, когда ловите глюк в работе через JTAG делайте:
testcspeed 0x200000
И подправляйте настройки RDI под реальную частоту ядра.


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


Автору - длина шлейфа между Link'ом и таргетом небезгранична, оптимально - 10-20см, иначе на больших скоростях могут быть проблемы.

defunct Вы дышать глубже не пробовали?

Проще всего списать все на нестабильность JTAG интерфейса и производителя чипов.
Сложнее разобраться в чем же на самом деле проблема и устранить ее раз и навсегда.

конкретно у этого процессора с JTAG'ом все ОК, как впрочем и у других SAM7.

Сложнее да. Тем более что в RDI (и в j-flash)пробовал и настраивать точно как Вы говорите ( кварц 18432000) и adaptive clocking включать. Проблем вобщем-то не было почти.
- jlink при любых настройках не может стереть кристалл с загруженной программой с первого раза.
- RDI работает стабильно при размере прошивки меньще 140кб. У меня сейчас около 170. При чистом процессоре все зашивается постоянно без проблем. При уже загруженном при прошивке страших секторов (>700) иногда (относительно редко) возникает ошибка unable to halt arm core. core does not stop. Естественно дальше сектора на котором "отвалилось" прошивка не идет. Вот и думай что хочешь. есть однако мнение что дело все же в шлейфике, надо бы его заэкранировать.

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

А не включает ли ваша программа собаку?

Кстати да! Включает. Вернее не выключает. Установлин лишь бит WDT_DEBUGHALT. И из-под отладчика он даже не всегда работает. Проц там в не которые моенты не презагружается по нему если я через отладчик проц запустил. Однако он вроде не должен включатся до сброса питания.
Надо попробывать установить битик Disable для отладки. Спасибо за догадку.

А поскольку этот регистр можно прописать лишь один раз, то прошивальщик и не может заблокировать собаку перед прошивкой. Выглядит логично. Во всяком случае у меня похожие симптомы: во время прошивки приложения через MT-Link срабатывает собака, проц попадает в мой загрузчик и, обнаружив несовпадение CRC приложения начинает весело моргать светодиодом. При этом процесс заливки подвисает до выдергивания MT-Link. Поскольку загрузчик собаку не трогает, то повторная перепрошивка проходит без проблем.

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