Hallo, ich habe vor einiger Zeit einen Schwung Atmega64L im MLF64 Gehäuse im günstig bekommen (die waren noch nie gelötet) und wollte nun meine erste Applikation damit erstellen. Ich wollte dafür gerne die Arduino - IDE benutzen, da mir diese bereits durch einige RepRap - Apps bekannt ist. Als erstes muss dazu der Bootloader für ISP in den Chip rein. Dazu habe ich das Projekt "Arduino as ISP" compiliert und dann in einen Mega2560 Arduino/Genuino - China Klon geschossen. Nun versuche ich über den Mega2560 als ISP für meinen Ziel - Chip AtMega64L über AvrDude (integiert in die IDE) den bootloader zu brennen. Da die IDE den AtMega64L nicht anbietet musste ich zuvor noch einen zusätzlichen Board Support laden. Nun taucht auch der ATMega64 auf. Beschaltet habe ich den AtMega64L folgendermaßen: (pin2) MOSI bzw. PDI an pin 12 des Mega (pin3) MISO bzw. PDO an pin 11 des Mega (pin20) /RESET an pin 10 des Mega (pin11) SCK an pin 13 des Mega ich habe natürlich auch Masse verbunden. Am Oszilloskop sehe ich das /RESET wackelt. SCK wackelt und MOSI wackelt auch. Allerdings MISO (der output des AtMega64L) ist nicht zum Leben zu erwecken. AvrDude erzählt mir etwas von falscher Chip - Kennung - Klar der OUTPUT floated ja. Da kommt jedes mal was anderes raus, es sei denn ich setze noch einen pullup dazu. Dann bekomme ich als chip kenneung 0xFF 0xFF 0xFF Ich habe auch versucht einen externen 8MHz Quarz zu schalten. Dieser schwingt allerdings nicht. So langsam gehen mir die Ideen aus was ich noch versuchen könnte. Muss ich die Timings des "Arduino as ISP" Projekts anzweifeln? Ich wäre für gute Tipps dankbar. Danke und Gruß Thilo
Du musst den Chip mit Strom versorgen, an allen (A)VCC/GND Paaren. Abblock- Kondensatoren nicht vergessen.
Ich hatte mir die Versorgung bei der Pin - Konfiguration geschenkt. Ja - auf dem Steckbrett war ich jetzt mit den Kondensatoren etwas sparsam. Ich werde einige dazu packen. Also: Pin 64, 52 und 21 mit +5 Volt versorgt. Pin 63, 53 und 22 an Masse angeschlossen. Gruß T.
> (pin2) MOSI bzw. PDI an pin 12 des Mega > (pin3) MISO bzw. PDO an pin 11 des Mega > (pin20) /RESET an pin 10 des Mega > (pin11) SCK an pin 13 des Mega In meinem Datenblatt steht:
1 | MOSI (PDI) PE0 I Serial Data In |
2 | MISO (PDO) PE1 O Serial Data Out |
3 | SCK PB1 I Serial Clock |
Angehängte Dateien:
-
Atmega64L.png
100 KB
S. Landolt schrieb: >> (pin2) MOSI bzw. PDI an pin 12 des Mega >> (pin3) MISO bzw. PDO an pin 11 des Mega >> (pin20) /RESET an pin 10 des Mega >> (pin11) SCK an pin 13 des Mega > > In meinem Datenblatt steht: >
1 | > MOSI (PDI) PE0 I Serial Data In |
2 | > MISO (PDO) PE1 O Serial Data Out |
3 | > SCK PB1 I Serial Clock |
4 | >
|
Jaaa ? siehst Du ein Problem welches mir entgeht? Gruß T.
OK, die Pins auf der Seite des "Arduino as ISP" sind konfigurierbar. Ich habe halt 10 - 13 genommen. Gruß T.
Was soll den das ? Hubert G. schrieb: > Den 10µ Elko zwischen Reset und GND beim Mega eingefügt? So wird er nie die ATMEL Application Note lesen und diesen Fehler finden !
> Den 10µ Elko zwischen Reset und GND beim Mega eingefügt? Damit ist das Arduino Board gemeint, das als ISP Programmer genutzt wird. Richtig? > So wird er nie die ATMEL Application Note lesen und diesen Fehler finden Welche Note genau meinst du? Ich dachte bislang, dass es hierbei um eine Eigenart der Arduino Software bzw. Module geht.
Stefan U. schrieb: >> Den 10µ Elko zwischen Reset und GND beim Mega eingefügt? > > Damit ist das Arduino Board gemeint, das als ISP Programmer genutzt > wird. Richtig? > >> So wird er nie die ATMEL Application Note lesen und diesen Fehler finden > > Welche Note genau meinst du? Ich dachte bislang, dass es hierbei um eine > Eigenart der Arduino Software bzw. Module geht.
1 | Er meint wohl das hier: |
2 | http://www.atmel.com/Images/Atmel-0943-In-System-Programming_ApplicationNote_AVR910.pdf |
Nein - Ich habe keinen Elko. Was soll der bringen? Die Reset-Leitung wird vom ISP gesteuert. Ein Elko stört dabei nur... Gruß T.
> Er meint wohl das hier: > http://www.atmel.com/Images/Atmel-0943-In-System-Programming_ApplicationNote_AVR910.pdf Da steht aber nichts von einem zusätzlichen Elko und hat mit dem Arduino ISP Sketch ziemlich wenig zu tun.
Stefan U. schrieb: >> Er meint wohl das hier: >> > http://www.atmel.com/Images/Atmel-0943-In-System-Programming_ApplicationNote_AVR910.pdf > > Da steht aber nichts von einem zusätzlichen Elko und hat mit dem Arduino > ISP Sketch ziemlich wenig zu tun. https://www.arduino.cc/en/Tutorial/ArduinoISP
Genau, ich wollte gerade von dieser Seite zittieren. > Was soll der bringen? Die Reset-Leitung > wird vom ISP gesteuert. Ein Elko stört dabei nur... Nicht die Reset Leitung zum Target, sondern die Reset Leitung vom µC, der als ISP Programmer verwendet wird. Warum? Gute Frage, dazu schweigt die Seite.
Thilo H. schrieb: > (pin2) MOSI bzw. PDI an pin 12 des Mega > (pin3) MISO bzw. PDO an pin 11 des Mega sollte das nicht eher: (pin12) MOSI bzw. PDI an pin 12 des Mega (pin13) MISO bzw. PDO an pin 11 des Mega sein?
Wie ich Eingangs schon sagte: Der Programmer tut es augenscheinlich. Die Signale wackeln so wie sie sollen. Ich konnte sogar die 0xAC 0x53 0x00 0x00 identifizieren. Aber die Antwort fehlt eben. Gruß T.
Toni R. schrieb: > Thilo H. schrieb: >> (pin2) MOSI bzw. PDI an pin 12 des Mega >> (pin3) MISO bzw. PDO an pin 11 des Mega > > sollte das nicht eher: > > (pin12) MOSI bzw. PDI an pin 12 des Mega > (pin13) MISO bzw. PDO an pin 11 des Mega > > sein? Steht anders in Datenblatt. Ich habe es aber trotzdem versucht. Erfolglos.... Gruß T.
Verbinde mal /Reset vom Target fest mit GND (anstatt mit dem ISP Programmieradapter) und schalte erst danach die Stromversorgung ein. Das hat bei mir in drei Fällen gehilfen, wo das Programm so fehlerhaft war, daß der µC sofort nach dem Start abstürzt. ISP Funktioniert auch, wenn /Reset fest mit GND verbunden ist.
Stefan U. schrieb: > Verbinde mal /Reset vom Target fest mit GND (anstatt mit dem ISP > Programmieradapter) und schalte erst danach die Stromversorgung ein. > > Das hat bei mir in drei Fällen gehilfen, wo das Programm so fehlerhaft > war, daß der µC sofort nach dem Start abstürzt. > > ISP Funktioniert auch, wenn /Reset fest mit GND verbunden ist. Habe ich drei Mal versucht. Keine Reaktion.... Meine Frage: Wenn die Dinger über einen ZIF - Sockel bereits gebrannt worden wären - sagen wir mal "verfused"! Wäre dann die Reaktion so - oder würde aus MISO etwas herauskommen? Gruß Thilo
Wenn (per Parallel-Programmierung) im Fuse High Byte das SPIEN abgeschaltet wurde. Oder wenn der interne RC-Oszillator deaktiviert wurde, in diesem Fall hilft ein (hinreichend hoher) externer Takt an XTAL1.
Zum Testen habe ich mal gerade einen Atmega88 - 20 in das Steckbrett gesetzt. Der Antwortet. Die Prozedur ist lt. Datenblatt gleich.... Als Signatur meldet AVRDude 0x1e930a Es liegt also nicht am Programmer. Es besteht natürlich auch noch die Möglichkeit, dass ich zwei von zwei Kandidaten kaputt gelötet habe. Sollte mir eigentlich nicht passieren. Aber ich nehme mir noch einen dritten vor. Wenn ich alles richtig verstanden habe kann nur ein parallel Programmer die Fuse Bits zurücksetzen? Gruß Thilo
Voraussetzung, daß die ISP Schnittstele funktioniert ist: - Stromversorgung liegt an allen Versorgung-Pins an und ist höher als die Schaltschwelle des evtl. per Fuse aktivierten Brown-Out Detektors. - Die per Fuse konfigurierte Taktquelle arbeitet. - Das /Reset Signal ist Low. Ja, er könnte verfused sein. Zum beispiel so, daß er eine Taktquelle an XTAL1 erwartet. Schließe da mal einen Oszillator an (mit 1-8Mhz).
> Wenn ich alles richtig verstanden habe kann nur > ein parallel Programmer die Fuse Bits zurücksetzen? Nein. Nur wenn SPIEN abgeschaltet wurde, geht seriell (natürlich) nichts mehr. Ansonsten kommt man seriell irgendwie dran, mit mehr oder weniger Aufwand.
Habe nun noch einen 4MHz Oszillator aus der Grabbelkiste dazu geschaltet. An XTAL1 angeschlossen. Keine Änderung. Ich werde jetzt nochmal einen auf eine Adapterplatine löten.... Gruß Thilo
OhhOooh es war doch die Lötarbeit.
Herzlichen Dank an euch. Ich muss zu meiner Entschuldigung anführen,
dass die Adapterplatinen nicht ganz passten. Die sind für qfn64 und
qfp64 ausgelegt. Der MFL chip passt nur gerade so drauf.....
avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is
"C:\Users\Hla\AppData\Local\Arduino15\packages\MegaCore\hardware\avr\2.0
.0/avrdude.conf"
Using Port : COM5
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega64
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
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 4 20 64 0 no 2048 8 0
9000 9000 0xff 0xff
flash 33 6 128 0 yes 65536 256 256
4500 4500 0xff 0xff
lfuse 0 0 0 0 no 1 0 0
9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0
9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0
9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0
9000 9000 0x00 0x00
calibration 0 0 0 0 no 4 0 0
0 0 0x00 0x00
signature 0 0 0 0 no 3 0 0
0 0 0x00 0x00
Programmer Type : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.03s
avrdude: Device signature = 0x1e9602 (probably m64)
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100%
0.01s
avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3f:
avrdude: load data lock data from input file 0x3f:
avrdude: input file 0x3f contains 1 bytes
avrdude: reading on-chip lock data:
Reading | ################################################## | 100%
0.01s
avrdude: verifying ...
avrdude: 1 bytes of lock verified
avrdude: reading input file "0xff"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100%
0.04s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xff:
avrdude: load data efuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100%
0.01s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: reading input file "0xd6"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100%
0.04s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xd6:
avrdude: load data hfuse data from input file 0xd6:
avrdude: input file 0xd6 contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100%
0.01s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0b11100001"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100%
0.01s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0b11100001:
avrdude: load data lfuse data from input file 0b11100001:
avrdude: input file 0b11100001 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100%
0.01s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude done. Thank you.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.