Полная версия этой страницы:
Программирование ATtiny12L
platerx
Oct 19 2006, 14:27
Есть ATtiny12L в ней уже что-то зашито. Подключил я её к LPT порту, пытаюсь запрогамить, используя режим Low-voltage Serial Downloading: посылаю комманду "Programming Enable", в ответ получаю ff ff ff ff (как я понимаю должно быть xx xx 58 xx). В чём может быть проблемма?
В даташите написанно , что если запрогрмирован FUSE RSTDISBL, то перепрогаммировать можно только в режиме "High-voltage Serial Programming", но этот вывод вроде используется в устройстве именно как ресет, т.е. FUSE RSTDISBL похоже незапрограммирован.
Могла ли микросхема просто выйти из строя, в результате перегрева(один нехороший человек пытался отпаять её 40 ватным паяльником)?
Или существуют другие причины, по которым она может так себя вести?
На счёт перегрева я похоже сморозил глупость!. Но может есть какие-нибуди другие внешние факторы, которые могли бы повлиять на её работоспособность?
Gennadiy_
Oct 19 2006, 16:25
Факторов много, и первый это ошибки оператора, если они не были фатальными, то:
Проверьте монтаж.
Поскольку "подключил к лпт порту" не раскрывает каким софтом вы пользуетесь=> правильно ли проходит вход в режим программирования (стр 53 54 Low-voltage Serial
Programming Algorithm)
Не обольщайтесь, МС может быть защищена от считывания, если, конечно, это вас интересует.
platerx
Oct 19 2006, 18:12
Софтом я пользуюсь своим, написанным "на коленке". Вроде всё делаю по даташиту: т.е:
Подаю напяжение питания, на ресете, и SCK при этом ноль, затем жду 50мс.
Затем вывожу последавательно 1010 1100 , 0101 0011 , 0000 0000, 0000 0000, читая по заднему фронту, и получаю в ответ только "1". Все временные интервалы взяты из даташита.
Gennadiy_
Oct 20 2006, 11:15
Вам надо разбить задачу на 2
Убедиться, что софт работает правильно.
Убедиться, что чип живой.
Вы в своем софте уверенны?
Проверяли свой софт закольцовыванием входа и выхода данных?
Чем вас не устроил чужой, проверенный софт?
Попробуйте увеличить временные интервалы, вы пишите про 50 мс , вы интервалы с высоковольтным режимом не перепутали?
В низковольтном Т sck должен быть более 2 T clk
Ваш чипе в схеме работал от какого генератора? с какой частотой?
Если от внутреннего то увеличивайте Tsck.
platerx
Oct 20 2006, 18:02
Закольцовывать пробовал, всё ОК.
Тактирование от внешнего RC генератора
Tsck прововал увеличиват до 500мс - ни чего не изменилось.
Я тоже склоняюсь к мысли, что надо взять заведомо рабочий чип и попробывать с ним, но это минимум через неделю.
defunct
Oct 20 2006, 20:28
Если у вас задача запрограммировать чип - то проще всего взять готовый рабочий программатор, и запрограммировать чип.
Если задача написать свой софт для программирования чипа, то и здесь готовый программатор не будет лишним (хотя бы для проверки).
Цитата
Затем вывожу последавательно 1010 1100 , 0101 0011 , 0000 0000, 0000 0000, читая по заднему фронту
не надо ничего читать по заднему фронту этой команды. Этой последовательностью вы переводите чип в режим программирования, и он вам не должен ничего "отвечать".
После входа в режим программирования сделайте задержку ~100ms.
Для чтения сигнатуры используйте команды чтения сигнатуры:
0x30 0x00 0x00 RR
0x30 0x00 0x01 RR
0x30 0x00 0x02 RR
на месте RR - ответ чипа.
platerx
Oct 21 2006, 08:24
2defunct:
Вот выдержки из даташита:
Цитата
When writing serial data to the ATtiny12, data is clocked on the rising edge of SCK.
When reading data from the ATtiny12, data is clocked on the falling edge of SCK.
Может я не правильно это понимаю, но в первом абзаце говориться, что при записи данных в мискросхему, они пишуться по переднему фронту, а читаются по заднему фронту.
Цитата
Wait for at least 20 ms and enable serial programming by sending the Programming
Enable Serial instruction to the MOSI (PB0) pin.
The serial programming instructions will not work if the communication is out of
synchronization. When in sync, the second byte ($53) will echo back when issuing
the third byte of the Programming Enable instruction.
А тут как я понимаю написанно что при посылке команды "Programming
Enable " в она должна возвратить второй байт этой команды, во время посылки третьего.
Может я что то не так понимаю ?
Команды чтения сигнатур я тоже посылал в ответ 0xff
defunct
Oct 21 2006, 23:52
Цитата(platerx @ Oct 21 2006, 11:24)

Команды чтения сигнатур я тоже посылал в ответ 0xff
MISO с MOSI часом не перепутали?
prottoss
Oct 22 2006, 04:11
Цитата(platerx @ Oct 20 2006, 02:12)

Софтом я пользуюсь своим, написанным "на коленке". Вроде всё делаю по даташиту: т.е:
Подаю напяжение питания, на ресете, и SCK при этом ноль, затем жду 50мс.
Затем вывожу последавательно 1010 1100 , 0101 0011 , 0000 0000, 0000 0000, читая по заднему фронту, и получаю в ответ только "1". Все временные интервалы взяты из даташита.
С чего вы взяли, что 0х58? Хотя в данной (двоичной) последовательности у Вас, как положенно 0х53... Вот как делаю я:
Код
UCHAR err = ACK;
// синхронизируемся с подключенным чипом
ReleasePorts(); // отключаем порты
CatchPorts(); // подключаем порты к ISP
AVR_DELAY_RESET(); // задержка
// 32 цикла попыток засинхронизироваться с программируемым МК
for(UCHAR c = 0; c < 32; c++)
{
// пытаемся вывести чип в режим программирования
// при посылке 3-го байта в SPI чип должен вернуть код предыдущей посылки
UCHAR ctrl_byte = AVR_PROG_EN();
ExSPI(0x00);
// получили верный контрольный байт - синхронизация выполнена
if(0x53 == ctrl_byte)
goto m1;
// если нет валидного возврата, то сдвигаем при каждой попытке строб
SET_SCK();
__delay_cycles(600); // задержка 50 мкс
CLR_SCK();
__delay_cycles(600);
}
// если мы не засинхронизировались,
// считаем, что устройство не найдено
ReleasePorts(); // отключаем порты
err = NACK; // посылаем код ошибки
m1:
PutChar(err);
platerx
Oct 23 2006, 19:53
Цитата
С чего вы взяли, что 0х58? Хотя в данной (двоичной) последовательности у Вас, как положенно 0х53...
Ой, конечно 0x53, я просто опечатался.
Схему я проверил ещё пару раз, вроде всё нормально, но не работает, и всё тут!
За новой микросхемой ехать не охота, модифицировал, я свой самопальный программатор для работы в высоковольтном режиме, переписал прогру. Посылаю ему команду чтения сигнатуры, он возвращяет первый байт 0x0e, должно быть 0x1e, следующие два байта правильные (0x90, и 0x05). С чем это может быть связано? Может микросхема вышла из строя ?
SasaVitebsk
Oct 23 2006, 20:32
Цитата(platerx @ Oct 23 2006, 22:53)

Цитата
С чего вы взяли, что 0х58? Хотя в данной (двоичной) последовательности у Вас, как положенно 0х53...
Ой, конечно 0x53, я просто опечатался.
Схему я проверил ещё пару раз, вроде всё нормально, но не работает, и всё тут!
За новой микросхемой ехать не охота, модифицировал, я свой самопальный программатор для работы в высоковольтном режиме, переписал прогру. Посылаю ему команду чтения сигнатуры, он возвращяет первый байт 0x0e, должно быть 0x1e, следующие два байта правильные (0x90, и 0x05). С чем это может быть связано? Может микросхема вышла из строя ?
Когда-то давно делал и смутно сейчас помню. Программатор могу выложить, но Вы ведь всё равно не будете разбираться. Помню, что в процедуру инициализации входил несколько раз. Тогда устойчиво работала. А вообще требуется максимально близко к даташиту. Ну и когда она "вошла", то ошибок я не помню. Чтобы вместо 1e 0e выдавала... %99 гарантирую, что какая-то ошибка.
defunct
Oct 23 2006, 21:11
Цитата(platerx @ Oct 23 2006, 22:53)

Посылаю ему команду чтения сигнатуры, он возвращяет первый байт 0x0e, должно быть 0x1e, следующие два байта правильные (0x90, и 0x05). С чем это может быть связано? Может микросхема вышла из строя ?
Сомнительно. Раз хоть что-то правдоподобное выдает, значит еще дышит.
ЗЫ: видел немало чипов которые возвращали по ISP все FF при попытке чтения сигнатуры, но тем не менее остальные функции продолжали работать.
Gennadiy_
Oct 26 2006, 16:01
вместо 1е приходит 0е, осмелюсь предположить
* софт съедает этот бит
* аппаратная часть неудачна, и меняется режим по постоянному току в процессе передачи посылки, что приводит к пропажам, такие фокусы должны зависеть от скорости передачи.
Может поделитесь схемой, наконец, легче будет вам помочь.
А лучше и софтом.
platerx
Oct 28 2006, 07:23
Что самое странное, флеш читается и пришется абсолютно нормально.
Могла ли по какой-то причине измениться сигнатура?
Праграмму прикрепил.
defunct
Oct 29 2006, 13:47
Возможно проблема в HPI_tranz()
За один раз там меняется только один пин порта, а это не есть правильно. Насколько помнится данные и "клок" надо менять одновременно,
от функции setpin лучше отказаться в пользу записи порта целиком -
формировать сигналы во временной переменной и выводить ее в порт.
platerx
Oct 29 2006, 15:07
Цитата(defunct @ Oct 29 2006, 16:47)

За один раз там меняется только один пин порта, а это не есть правильно. Насколько помнится данные и "клок" надо менять одновременно,
Позволю себе не согласиться с вами. Насколько я заню сначала выставляются данные, а затем даётся клок, дабы занести эти данные в регистр, а одновременно подавать данные и клок нельзя.
В подтверждение своих слов привожу начало страницы 52, из даташита на ATtiny12. Обратине вимание на tIVSH.
Нажмите для просмотра прикрепленного файлаПока рассматрива диаграмму заметил на ней ещё одну странную вещь:
там написанно, что tSHSL - это длительность лог нуля клока, а на диаграмме в этом месте лог 1 !
defunct
Oct 29 2006, 18:14
Вы обратили внимание в приведенной диаграме на время tSHOV.
Max = 32ns.
Используя setpin вы явно выйдете за пределы этого интервала, причем на очень много (в сотни-тысячи) раз.
Поэтому сказанное в моем предыдущем посте остается в силе.
platerx
Oct 29 2006, 19:00
Как я понял tSHOV - это время, которое дожно пройти после переднего фронта клока, прежде чем на выводе SDO появяться данные.
Т.е. по моему данные приведённые в таблице означают, что после того как был клок, данные появяться минимум через 10ns, максимум через 30 ns, а висеть они там будут до следуюшего клока.
А вы, как я понял думаете, что данные появляются через 10 ns, а пропадают через 32ns? Я тоже сначала так подумал, но в таком случае было-бы очень проблемматично их успеть считать.
Поправте меня пожалуйста, если я где то был не прав.
defunct
Oct 29 2006, 22:13
Цитата(platerx @ Oct 29 2006, 22:00)

А вы, как я понял думаете, что данные появляются через 10 ns, а пропадают через 32ns? Я тоже сначала так подумал, но в таком случае было-бы очень проблемматично их успеть считать.
Нет, я так не думаю.
Данные должны появиться не позже чем через 32ns после смены клока.
Я делал рабочий ;> программатор для AVR'ок, функция записи работает у меня так, как я описал выше (при записи одновременно выводится клок и данные)
пример для ISP:
["запись" байта данных]
Код
---> U8 Value - байт данных
{
for(i = 0; i < 8; i++)
{
temp = (0 << sSCLK)|(старший бит Value << sMOSI);
Value <<= 1;
LPTWrite( MyOutPort, temp);
sleep( x );
temp |= (1 << sSCLK);
LPTWrite( MyOutPort, temp);
sleep( x );
}
temp &= ~(1 << sSCLK);
LPTWrite( MyOutPort, temp);
sleep( x );
}
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.