Добрый день, господа. Помогите плиз. Пытаюсь написать программку для МК дабы с ее помощью программировать AVR (конкретно мегу128) через JTAG. Читаю статью http://www.gaw.ru/html.cgi/txt/doc/micros/...arh128/19_3.htm и никак не могу врубиться… На какие пины, что посылать… Последовательность команд там дана, но не разберусь куда ее надо выводить и в каком состоянии должны находиться остальные сигналы (TMS, TDI, TDO,TCK)? Хотя-бы временную диаграмму какую посмотреть… Может у кого есть такой опыт… или какая инфа …. Что-нибудь из разряда для полных чайников…

Добрый день

здесь есть кое-что

есть еще интересная книжка

Использование интерфейса JTAG для отладки встраиваемых систем. Ключев А.О., Коровьякова Т.А., Платунов А.Е. // Изв. вузов. Приборостроение. — 1998. — Т 41, № 5. — С. 45–50.

правда в электронном виде я ее не видел

Или еще одна книжеца

Embedded Systems Design ссылка

сорри за оффтоп,

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

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

Есть такое.
http://www.avrfreaks.net/Tools/ToolFiles/470/ - от Atmel - там JTAG ICE необходим.
http://www.floppyspongeonline.com/automati.../isojtagisp.php
http://home.telkomsa.net/antera/ - этот вроде через LPT работает

http://www-robotics.usc.edu/~ahoward/downl...isp-0.1-src.tgz - а это сорцы для чего-то странного, но как-то связанного с темой

2 sensor_ua спасибо.... очень интересно... будем разбираться

У меня вот тоже проблема возникла. Смонтировал и прошил Jtag Ice.
Не инициализируется. Сигнал на 14 вывод AtMega16 (RXD) проходит, а с 15 вывода (TXD) нет. Там висит логическая 1. Проверил все напряжения на выводах, вроде бы всё нормально. Может плохо работает кварц на 7.3728 МГц?
Подскажите где копать!!

Но когда мой контроллер ставишь на рабочую плату Jtaga, всё работает

Может, CKOPT не поставил, а кварц такой, что ему действительно плохо? Ещё был один нюанс с питанием таргета - если таргет не подключен, то иногда нужно затянуть VREFT на общий резистором в пару кОм.
Лучше вааще-то ссылать на вариант железа, а то говорим не совсем определенно.
Я когда-то такое железо придумывал - http://www.onembedding.com/files/jtag_vit/ работают пока - только у меня 10 шт.

Ну дык коль так, почему бы просто не купить JTAG-ICE / MkII?
Если у конторы нет денег чтобы купить отладчик за 50$, то можно сделать Evertool.
http://www.siwawi.arubi.uni-kl.de/avr_proj...tool/index.html

Да и идея не совсем понятна.. Какая разница сколько плат.. Хоть тысяча.. Отлаживаться программа МК будет на нескольких штуках, а все остальные будут просто клонами. Проверка должна вестись уже не через JTAG, а в конкретной системе, конкретными тестами, проверяющими функциональность устройства, а не МК.

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

На всякий случай советую посмотреть тут - http://www.purelogic.ru/programmator.html
можно попробывать переделать этот
дешево и сердито

На всякий случай советую посмотреть тут - http://www.purelogic.ru/programmator.html
можно попробывать переделать этот
дешево и сердито

А где в Москве это продается ?

Много зависит от того что конкретно требуется проверять.

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

Прошивку серийного номера, удобно зашивать в EEPROM средствами программы МК, по штатным протоколам вашего устройства, а не через JTAG...

Сори что вклиниваюсь, у меня иногда бывает что некоторые байты в EEPROM самопроизвольно слетают в 0xFF, почему такое может происходить (помнится была тема, но поиск на этом сайте оставляет желать лучшего)? По этой причине приходится во флэш хранить серийные номера...

Ошибка записи вероятно..
Я поступаю так. В eeprom храню 2 копии пакетов данных с CRC. Если сбойнет питание при записи конфигурации, то по крайней мере один пакет останется целым.. При вычитке eeprom'a проверяю CRC на предмет каким данным можно верить. Если CRC одного из пакетов испорченная, а второго целая - то испорченный пакет перезаписываю целым.

IMHO, серийный номер утройства не имеет никакого отношения к самой программе и очень в редких случаях может храниться в EEPROM - ему место только во FLASH (если хватает места и нет других супер вычурных пожеланий). Штатный протокол просто должен запросить у "программы" то, что она знает, где это оно лежит. Существет, правда, такое понятие, как серийный (как ни может показаться странным) номер программы и он никакого отношения к номеру устройства не имеет - храните где придётся.

Согласен.


А вот тут все с точностью до наоборот.
Номер устройства, это номер конкретного экземпляра устройства, с одной и той же прошивкой. Для того чтобы задать этот номер не нужно перекомпилировать программу. Поэтому он должен размещаться в памяти, которая не перетирается при смене прошивки - или в EEPROM или в области бутлоадера. Если его размещать в области бутлоадера, то
1. и программировать чип придется будлоадером во избежание стирания этого номера;
2. Бутлоадер придется править перекомпилировать или перелинковывать столько раз сколько всего серийных номеров устройств.

С eeprom будет гораздо меньше мороки, т.к. достаточно просто запрограммировать фуз EESAVE.


А вот номер или правильней сказать "версия" программы - вшивается в код программы и соответсвенно размещается во FLASH.

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

2defunct
Да не переворачивайте всё с ног на голову.
Если девайс перешивается (наладчиком, например, каким-нибудь) то чхать на все изыски насчёт размещения серийного номера - оно без системы учёта на предприятии глубоко до фени. Прекладывать этот вопрос на программиста, нихрена не должного знать сколько девайсов и за какими номерами когда БУДЕТ выпущено, - полный бред. Механизмы прозрачны и действительно они требуют восстановления номера после стирания, но это производственный вопрос. У меня девайсы тестируются на одной программе - ТЕСТОВОЙ, а выпускаются в свет с конкретной, согласно заказу. И это НОРМАЛЬНО. А повредить ячейку в EEPROM завсегда проще прямо из тела выполняемой программы, тем более стираетcя оно также легко, как FLASH. И какого хрена запрещать программисту полноценно пользоваться EEPROM только из-за пожеланий "начальника транспортного цеха"???

Это действительно предпочтительнее, но в некоторых случаях не есть удобно, например, если программа де-факто имеет серьёзные настройки работы, укладываемые в EEPROM при выпуске, а идентификация версии (охват контрольными суммами в том числе) может быть только с этими самиыми настройками - вопрос о номере тогда становится более философским, но формально по идентификации эти версии разные

Причем тут программист? Программист пишет функциональность устройства по ТЗ, если в ТЗ входит соответвующая функциональность по работе с S/N, то задачей программиста будет внести функцию для записи/чтения S/N... Естественно ему будет фиолетово кто и как будет пользоваться функцией.


Это не производственный вопрос, а вопрос стадии проектирования. Либо гравируем номер намертво либо рисуем карандашем, а потом думаем куда он делся.. (утрирую).


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


Перечитайте мой предыдущий пост. Почему неудобно S/N хранить во FLASH я написал там. Могу повторить другими словами:
Для хранения во флеш программу придеться перекомпилировать/перелинковывать столько раз сколько серийных номеров, плюс при обновлении прошивки S/N сотрется.

Мотивация непонятная. Причем тут начальник транспортного цеха? И кто мешает программисту использовать eeprom так как ему нравится? Если S/N нужны только начальнику транспортного цеха, тогда маркировать надо плату или корпус устройства. Желательно снаружи жирным красным шрифтом. Но ведь порой этот номер нужен для других целей, например для автоактивации каких-то встроенных функций, когда заказчик за них заплатит.


Причем тут настройки программы к версии прошивки? Вы никогда не добавляете новую функциональность? И никогда не случалось видеть баги в прошивке?


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

Надеюсь, что насчет последнего я ошибаюсь.

Хотя не совсем по теме топика, но хранение серийных номеров и версий для меня очень интересна. Забавно, но разные люди приходят к одним и тем же решениям. Иногда по разным мотивам.

Я пока не остановился на конкретном способе и с любопытством слежу за вашим спором. Я, как правило поступаю так как defunct. Версию проги всегда размещена во флэш.(Идёт в тексте программы) Даже когда она никак не выдаётся наружу. Серийный номер обычно размещаю в EEPROM. Ещё одна причина, кроме названных defunct - CRC код программы. Таким образом он не модифицируется.

Хотя я размещал и во флэш. А специальная программа сразу вставляла серийный номер прямо в HEX прошивку. При этом не требовалось ни перекомпиляции, ни задания конкретного адреса. Она искала строку "s/n #" (пересчитывалась и менялась также и CRC флэш). Таким образом на эту программу не влияла версия прошивки. Впоследствии я всётаки перешёл на EEPROM и занесение серийного номера с помощью внешней программы в готовое устр-во с помощью недокументированных команд.

Я обычно размещаю серийник устройства во FLASH и зашивается он при прошивке бутлоадера. В "защищённой" - выделенной - области FLASH (обычно хватает одной станицы записи выше крыши) укладывается посредством бутлоадера CRC программы и флаг необходимости эту самую CRC проверять. Серийник прораммы, а также прочая текстовая инфа обычно генерируется с помощью асмовых макросов в специальный файл, который прилинковывается к программе автоматом. Программа знает только адрес, по которому должен быть номер девайса и он контрольной суммой программы не охватывается.

Как склеивать программу и прочая перед прошивкой в случае отсутствия загрузчика - маленький технический вопрос - HEX2BIN, склейка BIN, затем BIN2HEX.
У меня номера-то есть, а у поклонников EEPROM при использовании камней без EEPROM - полное отсутствие области определения)) Если вааще нужно получать удалённо и/или не раскрывая девайс инфу о нём, то серийники нужны. Так вот я утверждаю, что серийный номер девайса вписывается на производстве (например, даже, на заводике за тридевять земель), а не в программистской кандейке. Но при этом производству плевать где серийник девайса лежит - лишь бы было. А вот программисту не плевать, если ему кристалл дают, но говорят, что эту, эту и эту ячейки EEPROM трогать нельзя, да и вааще лучше не пользоваться этой самой EEPROM;))
Как только способ идентификации программы учитывает уникальность по контрольной сумме, то при любом изменении содержимого, охватываемого этой самой контрольной суммой, появляется новая уникальная версия (со своей контрольной суммой). Если такое утверждение не принимается, то все сериализации - филькина грамота и нужны для очковтирательства.

Спасибо за идею насчёт замены CRC - попробую обязательно.