Всем привет.

Решил Сам собрать себе дисковери кит на базе at91sam7s64-ek. Подарили мне китайский J-Link 8 c прошивкой 3.20. Недолго думая я посетил сайт производителя SEGGER и скачал от туда версию 4.76е. Пере прошил проггер на эту версию с новым серийником. Использовал кейген для лицензий (установились все кроме GDBserver). Использую IAR ARM 6.3, ОС - Windows 7 ultimate. Пробовал зашить его и включить debug, но выдал ошибку по RDI, перезагрузил программатор и плату, потом выдал ошибку: BAD JTAG communication write to IR: expected 0x1, got 0x0 <TAP command : 15> @ off 0x5. Потом опять перезагрузил, но выдало уже FAiled to measure total IRlen. И так замкнутый круг.

Запустил J-link arm консоль.
Выдал:
VTARGET: 3.31 V
IRLEN: 04, IRPrint 0x1, ARM7TDMI CORE

Значит проц то J-LINK видет. НО!!!!

Запускаю команду testwspeed на скорости 100 кГц. И выдает Write test failed. Пробую testcspeed - выдает NO RAM available @ address 0x0. Пробовал на скоростях от 10 кГц и выше
Опять перезагружаю все вместе с программой J-link arm , но выдает уже IRLEN: 04, UNKNOWN DEVICE.
Опять перезагружаю. Появляется IRLEN: 04, IRPrint 0x1, ARM7TDMI CORE, выставляю скорость в 4 кГц, выдает BAD JTAG communication...

Со стороны своей платы все прозвонил - ничего не замыкает, все ножки правильно подключены к J-LINK. Все необходимые линии подтянуты, как на схеме ATmel.
Пробовал и с JTAG_SEL играть - резистором 5 кОм на + и на -. На плюс подтягивал - совсем не работало. На минус - работало. По описанию по идее там внутренняя подтяжка 15 кОм
на землю. Так что я думаю это излишне.
Со стороны J-LINK не припаял только nTRST - потому что некуда.

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

Заранее спасибо.

Возможно, что у вас проблема, аналогичная описанной здесь
Spartan-6 и китайский клон USB кабеля

На эту мысль наводит факт, что у вас J-Link ARM console видит чип, т.е., энумерация устройств в JTAG-цепочке проходит нормально, но последующие операции терпят крах. Вкратце - проблема заключалась в плохом контакте линии TDI (где-то на переходнике между USB кабелем и разъемом на плате).

Спасибо огромное за мысль!!!

Я ведь тоже китайский переходник с 20-pin разъема на другие разъемы использую!!!

Надо будит разобраться с ним.

Еще момент нашел статью одну про китайских J-LINK, пишут что ставить версию SEGGER J-LINK надо не больше 4.24, а у меня 4.76е. Стоит ли делать downgrade, если он меня хоть как то дышит?

Про такие тонкие моменты J-Link'ов ничего не могу сказать. Но если знаете, как делать не только downgrade, но и upgrade, и вообще, как восстановить состояние - то почему не попробовать все варианты?

Делал и апгрейд и даунгрейд - тоже самое. Попробую заново свой КИТ сваять. И кстати сейчас уже жалуется, что TDO все время на выс. уровне и проц. совсем видеть перестал

Сообщение отредактировал max_mart - Oct 2 2013, 16:10

Ну, раз не получается методом научного тыка, пора, наверное, применить метод научного анализа

А именно - начать постепенную локализацию проблемы. Для начала определить - это проблема платы, или USB кабеля. У вас есть возможность проверить JTAG-цепочку на плате с помощью какого-нибудь заведомо работающего широко распространенного JTAG-кабеля с бесплатной поддержкой низкоуровневой JTAG-отладки (Altera: ByteBlaster, USB Blaster; Xilinx: ParallelCable или Platform Cable)? Так можно было бы проверить сторону платы.

Спасибо большое за ответы и желание помочь. Я раньше все время только с пиками, да с аврками и иксмегами работал только и беды не знал. А вот сейчас нужна мощь и проблемы пошли. Да и этих армов в запасе около 40 штук. Вот и решил начать грызть гранит науки ARM.

нету. имеется ввиду, тот который работает от LPT? У меня ведь и LPT, то нету.

У меня вот, что недавно получилось:

Написал пробную программу для at91sam7s64 в IAR ARM 6.30 , чтобы узнать в чем дело. Значит ситуация следующая:
1) Проект отканфигурирован под дебаггер RDI j-link 8, настройки linker - at91sam7s64.icf. Output converter - поставил создать дополнительный binary файл. Почему после компиляции этот файл весит 1 кб, а другой файл .out 32кб?
Когда нажимаю download and debug, то вылазиет ошибка Failed to measure CPU clock frequency, но почему-то в отладку заходит после нажатия ОК. Что это может значить? При этом, если я использую J-link commander, то он выдает ту же ошибку TDO constant high!!!
2) Пробовал через SAM-BA 2.12 прошить. Сначала выполнил команду Eraseall. Затем попытался загрузить, создавшийся .bin в ARM. Операция прошла успешно. Но запрограммированные функции не выполняются. Правильно ли я зашиваю? Почему bin весит 1 кб.?
Поэтому и возникают выше пречисленные вопросы. Помогите, пожалуйста, найти на них ответы.

Для PLL выставил 1.5 кОм, 1нФ, 10 нФ, как в ките. НО!!!

Не понятный момент: PLL, если высчитывать по атмеловскому калькулятору, то при делителе 5 и умножителе 25 (как в шаблоне проекта) = ~92,16 MHz. И нужно поставить якобы 874 Ом, 11нФ, 1нФ

Как это понимать? На что ссылаться?

Жаль. ByteBlaster - на LPT, USB Blaster - на USB. В принципе, можно и другие JTAG кабели использовать, лишь бы была уверенность в их 100% работоспособности, и софтина была бы, которая умеет с ними работать и дает доступ к низкоуровневым операциям с JTAG - например такая, как open source'ная Universal JTAG (UrJTAG).

По работе с Atmel ARM'ами я не советчик - у меня до них руки не доходили пока. Разве что-нибудь замечу из самых общих инженерных соображений - это пожалуйста.


Из того, что я знаю, .out файл и есть исполняемый файл. А что за binary файл размером 1 кБ? Объектник? Если так, то понятно, откуда разница - библиотеки прилинковались, скорее всего.


Похоже, у вас все-таки есть какие-то низкоуровневые проблемы. Точнее не скажешь пока. То ли железка имеет проблему, то ли firmware не совсем корректно что-то делает.... Я бы присмотрелся к этому коммандеру, изучил бы документацию на него. Судя по всему, он как раз мог бы помочь с низкоуровневой отладкой JTAG соединения с target'ом. Наверняка там есть что-то типа команды, в цикле производящей считывание ID чипов в JTAG цепочке, или еще что-то в этом роде. Это было бы большим подспорьем. Хорошо бы после изучения документации опробовать кабель на 100% работающем устройстве (неважно, с каким чипом - лишь бы его ID был известен).

1) стереть процессор пином ERASE
2) что за кварц на процессоре стоит? Поставить не сильно высокочастотный (8..18.432). Убрать конденсаторы с него.

В таком состоянии НЕ ШИТЬ ничего, а погонять те самые тесты из J-LINK COMMANDER

Всем Привет.

Проблема решилась.

Дeло оказалось в PLL. И очень странная ситуация: Сначала использовал обвеску из 1.5 кОм, 1 нФ, 10 нФ с настройками PLL: делитель 5, умножитель 25, PLL_counter 28 (845 мкС). Это не работало. Скачал программу калькулятор PLL. И оказалось совсем другое, что резистор нужен не 1.5 кОм, а 1 кОм, а для конденсаторов 1 нФ и 10 нФ, нужно выставить делитель не 25, а 23. Заработало, но с глюками. Выставил PLL_counter 33 (1000 uS) - глюки пропали.

Почему такая разница??? В чем кроется подвох?

Программирую через SAM-BA. Почему-то, если не отключусь от PA16 (ножка для SAM-BA), то может не запуститься ARM, а может и заработать моя прошивка. В чем может быть причина?

Да и почему-то не обрабатывает одновременное нажатие 2-х кнопок и даже не инициализируется процессор. Но это лишь в том случае, если этот код используется (не закомментирован). А когда я его комментирую, то проблем нет и я их использую по отдельности. процессор инициализируется.

Код:

Данным способом я уже давно пользуюсь, но только на 8 битках и он работает на УРА. В чем может быть проблема?

Заранее спасибо

Забыл указать, что среда программирования IAR ARM 6.30

Сообщение отредактировал IgorKossak - Oct 15 2013, 13:07

Я бы посоветовал подробнее поизучать инициализацию PLL. Очень часто встречается, когда в PMC_MCKR одной операцией заносится и новый источник тактирования (CSS) и новый прескалер (PRES) при переходе со Slow clock на PLL clock. Неоднократно наблюдал, когда контроллер впадает в ступор и наблюдаются всякие чудеса. После переделки (сначала PRES, MCKRDY, потом CSS, MCKRDY) неработоссобная плата начинала вести себя адекватно и подвисаний не замечено.

ЗЫ. И симптомы похожие: то запустится через 2 минуты, то сразу. Меняя элементы PLL, топологию разводки кварца, как будто наступает улучшение, но при длительном тестировании все равно наблюдаются подвисания, так что посмотрите как у Вас идет инициализация.

Кварц стоит на 18.432 МГц, но обвязка из конденсаторов не по 15 пФ, а по 12 пФ. Но я не думаю, что они могут влиять так. Или я не прав?

Да и 2 танталовых конденсатора по 10 мкФ по питанию ядра и регулятора напряжения. Но по идее это тоже не должно влиять. На осциллографе помех и искажений по питанию не наблюдал.

Сообщение отредактировал max_mart - Oct 14 2013, 19:26

В каких-то случаях и это может иметь значение. Но DmitryM дал хороший совет - проверьте, какая у вас последовательность записи в регистры настройки PLL.

Традиционный вопрос - тактирование PIO контроллера включено?

Да. Тактирование контроллера перефири (PIO) включено.

p_pPMC->PMC_PCER = 1 << AT91C_ID_PIOA;