ATMega328P-AU + Arduino Mega2560

[Proxy]

Хотел записать загрузчик на ATMega328P-AU с помощью Arduino Mega2560 в качестве ISP программатора (и используя их же среду), но не могу понять что делаю не верно. Ах да, хардварную часть я проверил как мог (ISP выводы моей самоделки прозваниваются с соответствующими ногами, ISP между собой не замкнуты, питание приходит (5В от самой Arduino), reset тоже приходит, отключение любого одного провода меняет код ошибки (пишет про ошибку протокола, например, но были и другие ошибки), т.е. платы соединил верно, насколько я могу понять. Если нужно, то могу сделать схему).
Вот такое возвращает avrdude:

avrdude: Device signature = 0xfeffff
avrdude: Expected signature for ATMEGA328P is 1E 95 0F

Мне показалось 0xfeffff подозрительным. Я думал, что в качестве сигнатуры он принял какие-то иные данные (ответ или фрагмент ответа на что-то или же 4 f подряд могли бы указывать на то, что часть битов искажаются из-за плохого соединения), начал проверять хардварную часть, но вроде всё верно. Затем я подумал, что это происходит просто из-за рассинхронизации, попробовал в среде выбрать другую плату (вообще их среда как бы не должна работать с самими контроллерами, только в составе их платы, но оно подключается к SPI интерфейсу мк, а остальное не важно) тоже с ATMega328P, но с частотой 8MHz (8MHz без внешнего кварцевого резонатора, впрочем я и не разобрался что мк использует в данный момент в моём случае, физически 16MHz кварц и керамические конденсаторы 22pF подключены на выводы TOSK1, TOSK2, на питание подано 5В, т.е. он вполне может в этом случае работать на 16MHz), затем перепробовал все поддерживаемые платы с 328P, но тщетно.

Сейчас у меня возникло 5 вопросов:
1) Может ли быть так, что физически всё работает корректно и у ATMega328P-AU реально сигнатура 0xFEFFFF (т.е. не 0x1E950F)?
2) Если да, то что будет, если я использую параметр -F и проигнорирую проверку сигнатуры? Если я установлю некорректный загрузчик, то что будет? Ничто же не помешает мне в дальнейшем записать корректный?
3) Верно ли я "подтягиваю" сброс 22K резистором на VCC? Может по умолчанию там всё же должен быть 0 и соответственно подтягивать нужно было на Gnd (хотя везде сказано иное)? А ведь там есть встроенный резистор и я делаю это зря, да? Моя проблема никак не может же быть связана с самопроизвольным сбросом, если avrdude всё же получает какую-то информацию с мк (и получает ли на самом деле?)
4) Какая примерно максимальная длина проводов от arduino в качестве программатора до моей платы с мк должна быть использована в моём случае? Я так понимаю, что довольно небольшая, 40см — это однозначно запредельно много или нет?
5) Чем можно было бы записывать загрузчик через этот необычный программатор (он видим как устройство на COM30 и имеет свой специфический протокол) и чтобы это было наглядно, а не в слепую только с выводом сообщения об ошибке или успешном завершении? Может имеет смысл забросить эту задумку и использовать RS232 вместо этого программатора (на стационарнике интегрирован мп)?

[Proxy]

UPD: Что-то где-то изменилось. Теперь возвращается сигнатура 0xffffff (до этого было 0xfeffff). Пробовал отключать MISO и MOSI, если хть один из них отключен, то доходит до этого же шага, но сигнатура в обоих случаях становится 0x000000. Т.е. со всеми проводами 0xffffff, когда программатор на самом деле ничего не получает или ничего не шлёт и ничего не получает — 0x000000.
Искать проблемы с соединением?

UPD2: без SCK тоже доходит до проверки сигнатуры, но сигнатура без SCK возвращается вообще произвольная каждый раз. Без Reset`а avrdude подвисает секунд на 8, затем выводит певый раз:

avrdude: stk500_program_enable(): protocol error, expect=0x14, resp=0x50
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.

Последующие разы (вплоть до перезагрузки программатора)

avrdude: stk500_getsync(): not in sync: resp=0x00

[Proxy]

Хм, а вот все ответы:

C:\Program Files\arduino-1.0.1\hardware/tools/avr/bin/avrdude -CC:\Program Files\arduino-1.0.1\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM30 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

avrdude: Version 5.11, compiled on Sep 2 2011 at 19:38:36
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "C:\Program Files\arduino-1.0.1\hardware/tools/avr/etc/avrdude.conf"

Using Port : \\.\COM30
Using Programmer : stk500v1
Overriding Baud Rate : 19200
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Send: 0 [30] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
AVR Part : ATMEGA328P
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PC2
RESET disposition : dedicated
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :

Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 20 4 0 no 1024 4 0 3600 3600 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
flash 65 6 128 0 yes 32768 128 256 4500 4500 0xff 0xff
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
hfuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
efuse 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
lock 0 0 0 0 no 1 0 0 4500 4500 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00

Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
avrdude: Send: A [41] . [80] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [02]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [01]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [12]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [98] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
avrdude: Send: A [41] . [84] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [85] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [86] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [87] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [89] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: Send: A [41] . [81] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [01]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [12]
avrdude: Recv: . [10]
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: P [50] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: V [56] 0 [30] . [00] . [00] . [00] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff]
avrdude: Recv: . [10]
avrdude: Send: V [56] 0 [30] . [00] . [01] . [00] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff]
avrdude: Recv: . [10]
################avrdude: Send: V [56] 0 [30] . [00] . [02] . [00] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [ff]
avrdude: Recv: . [10]
################################## | 100% 0.06s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude: Send: Q [51] [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]

avrdude done. Thank you.

[Хакер]

1) Может ли быть так, что физически всё работает корректно и у ATMega328P-AU реально сигнатура 0xFEFFFF (т.е. не 0x1E950F)?

Может быть просто мёртвая Мега. Может быть обрыв по линии MISO с небольшой ёмкостной связью.

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

А чип-то хоть вообще читается?

3) Верно ли я "подтягиваю" сброс 22K резистором на VCC? Может по умолчанию там всё же должен быть 0 и соответственно подтягивать нужно было на Gnd (хотя везде сказано иное)? А ведь там есть встроенный резистор и я делаю это зря, да? Моя проблема никак не может же быть связана с самопроизвольным сбросом, если avrdude всё же получает какую-то информацию с мк (и получает ли на самом деле?)

Не понял. У тебя просто пуллап или RC-цепочка?

5) Чем можно было бы записывать загрузчик через этот необычный программатор (он видим как устройство на COM30 и имеет свой специфический протокол) и чтобы это было наглядно, а не в слепую только с выводом сообщения об ошибке или успешном завершении? Может имеет смысл забросить эту задумку и использовать RS232 вместо этого программатора (на стационарнике интегрирован мп)?

Не понял, что за необычный программатор? Программатор на базе Arduino? Он использует протокол STK500, насколько я помню. И ты уверен, что тебе так необходим бутлоадер?

[Proxy]

Не понял. У тебя просто пуллап или RC-цепочка?

пулап. 22 кОм резистор между reset и vcc.

Он использует протокол STK500, насколько я помню.

О, спасибо. Об этом писал avrdude в процессе, но я не заметил даже (Programmer Type : STK500).

А чип-то хоть вообще читается?

Не пытался проверить.

И ты уверен, что тебе так необходим бутлоадер?

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

ЗЫ. Нашёл по описанию, что сигнатура 0xFFFFF часто вращается при плохом соединении.

[Хакер]

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

Почему именно бут?

Видимо в моём случае я использовал слишком длинные провода (обычная витая пара сантиметров около 40), нужно снизить период SCK?

Ээ. И как распределены SPI-линии по парам? Одна пара — одна линия?

[Proxy]

Почему именно бут?

Его компилировать не надо и он небольшой.

Ээ. И как распределены SPI-линии по парам? Одна пара — одна линия?

Сначала MISO и MOSI были в одной паре, SCK и RESET в другой, потом понял, что так они будут друг-другу мешать и размотал пары на отдельные проводники. На витую пару я указал, чтобы было понятно удельное сопротивление и сечение.

[Proxy]

Перепробовал все мыслимые и немыслимые решения проблемы (у людей всё сводилось к увеличению периода SCK и замене проводов, собственно 0xffffff сигнатура — проблема весьма распространённая), решил разобраться самостоятельно.

Сделал на коленке кое-какой простенький код для диагностики моей проблемы с ISP, который:
1) сбрасывает ведомое устройство: устанавливает на выводе SCK 1, ждёт 1сек, устанавливает на выводе SCK 0, ждёт 1сек, устанавливает на выводе RESET 1, ждёт 1сек, устанавливает на выводе RESET 0, ждёт 1сек
2) читает из серийного порта символы "1" и "0"
3) устанавливает на выводе MOSI 1, если принят символ "1" и 0, если принят не "1", ждёт 0.5 сек
4) устанавливает на SCK 1, ждёт 0.5 сек
5) устанавливает на SCK 0, ждёт 0.5 сек
6) читает с MISO
7) отправляет через серийный порт "1", если на MISO 1 или "0", если не 1
8) назад к шагу 2

что ожидал:
отправляем "101011000101001100000000" (включение режима программирования (сразу после сброса) + 8 произвольных символов, чтобы получить ответ)
получаем "000000000000000001010011" (16 произвольных символов + 8 ответ, повторяющий второй октет из посланных)
(а после планировал считать сигнатуру кодом 0011000000000000000000XX00000000, где XX - идентификатор октета сигнатуры: 00, 01 и 10)

что получил:
отправляем "101011000101001100000000" (включение режима программирования (сразу после сброса) + 8 произвольных символов, чтобы получить ответ)
получаем "000000000000000001010011" (точно то, что посылал, т.е. на отправку каждого бита отвечает тем же битом)

Но: если MISO вместо вывода MISO ведомого устройства подключить на землю, то получаем "в ответ" все нули, если на +5V, то получаем все единицы "в ответ", т.е. программатор верно считывает с MISO.

Естественно предположил, что MISO и MOSI где-то замкнулись, просветил дорожки лампой (плата с дорожками на одной стороне) — дорожки и контактные площадки нигде не сливаются, ноги контроллера чётко попадают на контактные площадки, замерил сопротивление между MISO и MOSI — тоже ничего, сопротивление выше диапазона чувствительности мультиметра в любом режиме (1 как при свободных щупах).

Затем подумалось, что просто общей земли между платами нет (программатор и ведомый мк), заменил провод - тщетно, на всякий случай проверил так же дорожки питания — тоже ничего, замерил напряжение на ведомом, замерил сопротивление между gnd`ами — ничего. Перекинул питание с внешнего БП на программатор (Arduino Mega2560 в качестве программатора диагностического девайса) — тоже ничего.

Затем посетила мысль, что в MISO просто плохой контакт (но мультиметр показывает, что нога с пином гребёнки связаны норм) и по MISO принимается просто шум. Подтянул MISO на ноль через 23K резистор — ничего, просто отпустил провод MISO в свободное плавание — тоже не то (считывает какие-то произвольные значения (шум), которые никак не коррелируют с тем, что посылается).

Что ещё может быть?

[Proxy]

Хммм, и всё же это шум, но принимает с MISO 1-в-1 с отправляемым по MOSI видимо из-за близости дорожек или ещё чего (однако MISO и MOSI не связаны, если верить мультиметру). Попробовал MISO подтянуть на GND не отключая от ведомого — считываются все нули. Родной ArduinoAsISP очевидно тоже на этом запнулся.
Однако выводы платы (все) и соответствующие ноги мк связаны между собой и не связаны с иными. Стало быть ведомый мк вообще никак не использует MISO ногу, она в каждый момент времени не связана ни с GND, ни с VCC по какой-то причине. Питание подаётся (замерял на ногах мк: VCC, GND, AVCC), использовал и питание от Arduino (конденсатор не использовал, т.к. на Arduino он и так есть на том выводе), использовал питание от внешнего БП (GNDы обоих плат соединены). Сброс тоже должен работать (садил на RESET и SCK светодиоды через резисторы 1K и на GND — всё как по задумке подаётся).
Перепроверил ещё раз на всякий случай ориентацию мк, сверил ещё раз оба VCC, AVCC, оба GND, MISO, MOSI, SCK и RESET со спецификацией и попробовал на всякий случай ещё сбросить дополнительно отключением питания перед сбросом по RESET.
Ума не приложу что ещё может быть не так и почему мк не стартует. При монтаже вроде не должен был перегреть (пошло как по маслу и каждую ногу жалом паяльника (заточено под иглу) лишь коснулся на мгновение (паяльной станции у меня нет, мощной лампы или фена тоже), на плате тоже дефектов не было ни на одном этапе изготовления, несмотря на плотность выводов у TQFP). Провода не путал. Насколько велика вероятность того, что он изначально не был живой?