Почему нельзя разъём для программирования использовать в целевой системе как рабочий? Я программирую через SPI, и потом этот разъём работает в устройстве, ноги-то обычные. Только одна нога - ресет - остаётся висеть. Конечно, на них выводятся "не рискованные" сигналы, чтобы часом не пожечь.

Я прошу прощения за назойливость, но уже девятое...

Есть, еще не упомянутый тут, кроссплатформенный пакет cdk-avr-tools,
в котором есть программатор через JTAG - javr.
В программаторе есть консольный интерактивный и пакетный режимы. Быстро и надежно работает, но без украшательств.

В сборке cdk-avr-tools-6.1-20060625.src.rpm есть и исходники и документация и готовые бинарники под windows и linux.

Простейший jtag программатор - кабель из нескольких проводов в LPT порт (но же altera-byte-blaster)

Сообщение отредактировал _kp - Jan 11 2009, 14:07

Извините У нас Интернета в связи с праздниками не было, надеюсь, что завтра появится. На крайний случай возьму флэшку, отправлю из дома.

1. За отправку команд у меня отвечает такая функция:
void Send_Instruction(TWord size, TByte data)
{
TMS_Low(); // Run-Test / Idle
TMS_Low(); // Run-Test / Idle
TMS_High(); // Select DR-Scan
TMS_High(); // Select IR-Scan
TMS_Low(); // Capture IR
TMS_Low(); // Shift IR
Shift_Data_Array(size, &data);
TMS_High(); // Update-IR -> New Instruction in Effect
TMS_Low(); // Run-Test / Idle
TMS_Low(); // Run-Test / Idle
}

Использую я ее так например: Send_Instruction(4,IDCODE);

Судя по тому, что я написал в Shift_Data_Array() такое:
...
if (bd&0x01)
macBitOn(PORT_JTAG,pinTDI);
else
macBitOff(PORT_JTAG,pinTDI);

JTAG_Delay();
macBitOn(PORT_JTAG,pinTCK);
JTAG_Delay();
macBitOff(PORT_JTAG,pinTCK);
bd>>=1;
...
первым идет младший бит.

2. Нужно подавать все указанные последовательности

Вот, например, чтение сигнатуры чипа:
void JTAG_ReadSign(TByte *sign)
{
TWord temp=0;
TWord key;
TByte ix;
TWord x[]={0x2308, 0x0300, 0x3200, 0x3300};

Send_Instruction(4,PROG_COMMANDS);
//enter reading signature mode
Send_Data_Output(15,(TByte *)&x[0],(TByte *)&temp);
for (ix=0; ix<3; ix++)
{
key = x[1]|(TWord)ix;
Send_Data_Output(15,(TByte *)&key,(TByte *)&temp);
//read signature byte
Send_Data_Output(15,(TByte *)&x[2],(TByte *)&temp);
Send_Data_Output(15,(TByte *)&x[3],(TByte *)&temp);
*sign++=(TByte)(temp&0xff);
}
}

А это сколько? И из каких соображений?


Тогда не очень понятно такое:
TDI Sequence: 0110011_00000000 (в частности, 2-я часть инструкции 9с)
TDO Sequence: xxxxxxx_oooooooo
Получается, мы в чип загоняем нули и в это время читаем из него данные, а потом уже качаем в него код (0110011). Зачем чипу этот код, когда мы уже все, что хотели, от него получили ??

Из таких:
void JTAG_Delay(void)
{
}
Ввел на всякий случай, в документации ничего не нашел, плохо искал, видимо.

Подозреваю, что адрес байта сигнатуры зависит от заданного в команде 9b, а команда 9c только вытаскивает байт сигнатуры и подтверждает окончание чтения, так что по логике противоречий нет. Кстати, вычитываются байты тоже младшим вперед.

Да я вот тоже не нашел, поэтому и спросил

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

Все-таки вопросы продолжаются… не работает…

1. (На всякий случай) В Programming Enable Register 0хА370 тоже загоняется младшим вперед?

2.

Насколько я понял, 3 мл. бита вгоняем при TMS=0, а 4-й – при TMS=1, т.е при этом мы выпрыгиваем из Shift-IR в Exit-IR.
Далее

А приведена последовательность (1,1,0) как будто мы еще в Shift-IR ––???

3.

Но в указанной таблице об этом ничего не говорится
У Вас void Send_Instruction( начинается с
TMS_Low(); // Run-Test / Idle
TMS_Low(); // Run-Test / Idle
…
– как я понимаю, это 2 клока при TMS=0. Связано ли это с вышеприведенной цитатой? Откуда инфа?

Говорю навскидку, потому что опять же не на работе У меня довольно длительное время не получалось считать верную сигнатуру чипа по не вполне понятной причине. В итоге победил это следующим образом: установил, что правильная сигнатура считывается только после подачи в самом начале команды входа в режим программирования. Нашел это эмпирическим путем, после этого пошло все как по маслу. Если кто-то увидел указание на это в документации, ткните меня, пожалуйста, носом То есть рецепт такой - сначала вводим чип в режим программирования, потом уже проводим все действия, даже те, которые по логике не требуют программирования. Я на этой проблеме просидел несколько дней, проверил по шагам весь код, сверил со схемами в документации, ничего не помогало, после входа в режим все заработало без всяких исправлений.
По поводу младшего-старшего - все команды и инструкции подаются одинаково, младшим битом вперед. Там есть еще небольшое уточнение по поводу самого старшего бита, но вроде бы в документации это описано.

Вы про PROG_ENABLE (0x4) ?
У меня с самого начала не было никаких сомнений, что с нее все должно начинаться; она у меня есть (по крайней мере, с моей точки зрения)

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

Вот много времени прошло, снова взялся за JTAG. Блин, ну не работает! Все то же самое.
Ресетится АВРка через JTAG, нормально выходит из ресета, а что-то чуть более сложное (прочитать преславутые signature bytes) - ни в какую. 333 раза прочитал в даташите про JTAG, вроде все далаю буква-в-букву...
Может кто подскажет, хоть в какую сторону копнуть?