реклама на сайте
подробности

 
 
> Програмирывание 4-х ATmega162 в цепочке., daisy chain JTAG
cpl
сообщение Jun 23 2010, 12:44
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 378
Регистрация: 6-12-04
Пользователь №: 1 340



Здравствуйте.
Есть 4 ATmega162 объединенных в цепочку по JTAG по следующей схеме

JTAG Разъем
TCK - на все 4 контролера
TMS - на все 4 контролера

TDI - на TDI 1 контролера, TDO1 на - TDI2, TDO2 на - TDI3, TDO3 на - TDI4
TDO - на TDO 4 контролера

Все сигналы(TDO, TDI, TMS, TCK, + TDO-TDI между контролерами) подтянуты к пинанию.

Пытаюсь прочитать сигнатуру контролера следующей командой:
jtagiceii.exe -mj -d ATmega162 -D 3,0,4,8 -s
в результате читается: 0x3f 0x3f 0x3f.

Что я делаю не так ?
Нужно ли подтягивать к питанию сигналы TDO-TDI между контролерами ?
Правильно ли задаю параметр -D 3,0,4,8 для последнего контролера в цепочке
так понимаю первая цифра задает сколько устройств в цепочке до нужного контролера ?
вторая задает число контролеров в цепочке после нужного контролера ?
Какие значение должны быть для последних двух цифр ?
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
zltigo
сообщение Jun 23 2010, 16:08
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244



Ну и наворотили sad.gif. Думаю,что тут редко кто так делал.
Ищите на сайте Atmel дополнительную информацию. Одно могу точно сказать, что очень многие Atmega принципиально могут стоять в цепочке только первыми sad.gif. Относятся-ли 162 к таким, я не знаю, но 16 и 128 точно "дефектные" - проектировалось в свое время устройство с CPLD, но соломки подстелили. Хотя в свое время натыкался на рекламу английской фирмочки, которая рекламировала некий софт и алгоритм решающий эту проблему.

P.S.
Посмотрел - у 162 такая-же errata:
CODE
IDCODE masks data from TDI input
The public but optional JTAG instruction IDCODE is not implemented correctly according to
IEEE1149.1; a logic one is scanned into the shift register instead of the TDI input while shift-
ing the Device ID Register. Hence, captured data from the preceding devices in the
boundary scan chain are lost and replaced by all-ones, and data to succeeding devices are
replaced by all-ones during Update-DR.
If ATmega162 is the only device in the scan chain, the problem is not visible.
Problem Fix / Workaround
Select the Device ID Register of the ATmega162 (Either by issuing the IDCODE instruction
or by entering the Test-Logic-Reset state of the TAP controller) to read out the contents of
its Device ID Register and possibly data from succeeding devices of the scan chain. Note
that data to succeeding devices cannot be entered during this scan, but data to preceding
devices can. Issue the BYPASS instruction to the ATmega162 to select its Bypass Register
while reading the Device ID Registers of preceding devices of the boundary scan chain.
Never read data from succeeding devices in the boundary scan chain or upload data to the
succeeding devices while the Device ID Register is selected for the ATmega162. Note that
the IDCODE instruction is the default instruction selected by the Test-Logic-Reset state of
the TAP-controller.
Alternative Problem Fix / Workaround
If the Device IDs of all devices in the boundary scan chain must be captured simultaneously
(for instance if blind interrogation is used), the boundary scan chain can be connected in
such way that the ATmega162 is the first device in the chain. Update-DR will still not work
for the succeeding devices in the boundary scan chain as long as IDCODE is present in the
JTAG Instruction Register, but the Device ID registered cannot be uploaded in any case.
request.


--------------------
Feci, quod potui, faciant meliora potentes
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd July 2025 - 11:54
Рейтинг@Mail.ru


Страница сгенерированна за 0.01372 секунд с 7
ELECTRONIX ©2004-2016