Gleich zu Beginn, ich bin in Lima, also hinter dem grossen Wasser im
Westen und einem grossen Gebirge. Hier kann man nicht eben mal was bei
einem Online-Anbieter bestellen und es morgen da haben.
Ich hab mir dann seitenweise Atmega Stoff durchgelesen, und hab es
geschafft einen Atmega8 zu erstehen. Letztendlich lande ich doch hier
bei einem Hilferuf.
Da ich hier in Peru schon desöfteren IC's angedreht bekommen hab in
denen nicht das drin war was draussen drauf stand, bin ich ein bisschen
skeptisch.
Also auf dem Atmega steht ATMEGA8L-8PU.
Ich verwende den unter verschiedenen Seiten (zBsp.: Ponyprog)
dargestellten AVR-ISP (den mit dem 74HC244, (selbstgebaut) und an den
Ausgängen die an den Atmega gehen also MISO, MOSI, SCK, RST tut sich
auch was wenn ich die Software sarte und lesen oder schreiben lasse.
jetzt das Problem: Ponyprog (Linux) avrdude (Linux) können womöglich den
IC lesen aber nicht schreiben.
Bleiben wir mal bei Ponyprog
wenn ich den Atmega auslesen will kommt erst mal dieser Fehler (-24)
klicke ich auf ignorieren beim Lesen liest das programm und zeigt mir
dann alle Bytes EEPROM, Flash auf FF und alle fuses leer (nicht
angekreuzt)
Klicke ich command->reset ... sagt er mir device resetted (oder so)
Will ich was schreiben. bleibt der Balken bei 0% eine Weile stehen, rast
dann auf 100%, ne weile nichts, dann der Verify und danach Write Error.
avrdude ziehmlich ähnlich. Beim Programmstart
xxx:~ # avrdude -pm8 -cstk200 -t -F
avrdude: AVR device not responding
avrdude: initialization failed, rc=-1
avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100%
0.00s
avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
avrdude: Expected signature for ATMEGA8 is 1E 93 07
avrdude> read eeprom
>>> read eeprom
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
avrdude> read flash
>>> read flash
0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
0030 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
|................|
avrdude> write eeprom 0 0 1 2 3 4
>>> write eeprom 0 0 1 2 3 4
avrdude (write): error writing 0x00 at 0x00000, rc=-6
avrdude (write): error writing 0x00 at 0x00000 cell=0xff
avrdude (write): error writing 0x01 at 0x00001, rc=-6
avrdude (write): error writing 0x01 at 0x00001 cell=0xff
avrdude (write): error writing 0x02 at 0x00002, rc=-6
avrdude (write): error writing 0x02 at 0x00002 cell=0xff
avrdude (write): error writing 0x03 at 0x00003, rc=-6
avrdude (write): error writing 0x03 at 0x00003 cell=0xff
avrdude (write): error writing 0x04 at 0x00004, rc=-6
avrdude (write): error writing 0x04 at 0x00004 cell=0xff
avrdude> write flash 0 0 1 2 3 4
>>> write flash 0 0 1 2 3 4
avrdude (write): error writing 0x00 at 0x00000 cell=0xff
avrdude (write): error writing 0x01 at 0x00001 cell=0xff
avrdude (write): error writing 0x02 at 0x00002 cell=0xff
avrdude (write): error writing 0x03 at 0x00003 cell=0xff
avrdude (write): error writing 0x04 at 0x00004 cell=0xff
avrdude>
avrdude> read lfuse
>>> read lfuse
0000 ff |.
|
avrdude> read hfuse
>>> read hfuse
0000 ff |.
|
avrdude> read lock
>>> read lock
0000 3f |?
|
avrdude> read calibration
>>> read calibration
0000 ff ff ff ff |....
|
avrdude> read signature
>>> read signature
0000 ff ff ff |...
|
avrdude>
Any ideas?
Ich bin absolut blank, was AVR controller angeht, sind meine ersten
Schritte, also nur heimlich lustig machen.
Gruss Ju
Hi nach Lima,
es kann sein, daß die Fuses, insbesondere die "CKSEL"-Fuses falsch
gesetzt sind (passiert mir ständig). Abhilfe schafft man sich
dergestalt, indem man 'nen externen Takt an Pin "OSC1" legt wobei die
Taktfrequenz ziemlich unkritisch sein darf. Hab mal was von "1 - 10 MHz"
gehört, von 3,57 - 8 MHz hab ich's schon selber erfolgreich
durchexerziert.
mfg Lötlackl
Takt an OSC1 ?? wie das?
nur an OSC1 oder zwischen OSC1 und OSC2?
Alle schaltungen die ich bis jetzt gesehen habe bauen einen Quartz mit 2
kerkos zwischen OSC1 und OSC2, meinst Du das?
ich habe zwei Quartze da, einen 4MHz und einen 32kHz (oder so) da.
Anhängende Frage dazu.
Wo finde ich denn was geschriebenes über die ISP communication an
MISO/MOSI/SCK und deren Pegel?
Beim Programmer hatte ich das Problem, dass die Parallelport-Pegel vom
Notebook nicht gereicht haben um die 244 Ausgänge hoch zu bringen wenn
ich das ganze mit 5V betrieben habe. Also läuft die ganze Geschichte
jetzt mit 3V.
Und wie lange müssen die Pegel stehen bleiben.
Hi,
>> Takt an OSC1 ?? wie das?>> nur an OSC1 oder zwischen OSC1 und OSC2?>> Alle schaltungen die ich bis jetzt gesehen habe bauen einen Quartz mit 2>> kerkos zwischen OSC1 und OSC2, meinst Du das?
nein, ich meinte 'nen Quarzoszillator, also entweder die viereckigen
Blechdinger oder einen auf die Schnelle mit 'nem TTL-Gatter aufgebautem.
Nimm den 4MHz-Quarz.
>> Anhängende Frage dazu.>> Wo finde ich denn was geschriebenes über die ISP communication an>> MISO/MOSI/SCK und deren Pegel?
Öhm, im Datenblatt, glaube ich.
>> Beim Programmer hatte ich das Problem, dass die Parallelport-Pegel vom>> Notebook nicht gereicht haben um die 244 Ausgänge hoch zu bringen wenn>> ich das ganze mit 5V betrieben habe. Also läuft die ganze Geschichte>> jetzt mit 3V.>> Und wie lange müssen die Pegel stehen bleiben.
Ich habe sowas immer mit 'nem seriellen Billigst-Programmer ('n paar
5,1V Z-Dioden, Widerstände und 'nem Transistor) erledigt. Äh... kann
denn der 74HC244 mit 3,3V-Pegeln umgehen? Vom HCT weiß ich's.
mfg Lötlackl
"Öhm, im Datenblatt, glaube ich."
richtig, ich hatte eines mit 22 Seiten, da stand dann nicht so viel
drin.
Hab jetzt ein besseres.
"kann denn der 74HC244 mit 3,3V-Pegeln umgehen?"
Laut meinem Datenblatt kann er das.
Die AVR Gurus sind wohl alle so in ihre Projekte vertieft das sie keine
Zeit für "Sozialmassnahmen" haben?
Ju wrote:
> Die AVR Gurus sind wohl alle so in ihre Projekte vertieft das sie keine> Zeit für "Sozialmassnahmen" haben?
Vielleicht. Vielleicht sind sie auch angesichts des fehlenden
Schaltplans des Programmers und des Targetboards einfach nur lust-
und/oder sprachlos ;-)
Hallo Ju!
Solche (oder ein ähnliche) Probleme hatten sicher schon viele. Ist Dein
Mega8 "fabrikneu" oder wurde der schon mal benutzt? Möglicherweise sind
dann die Einstellungen/Fuses verstellt, die die Taktquelle wählen, oder
eventuell sogar das ganze Device gesperrt. Wenn der AVr z.B. ein
Taktsingal von aussen erwartet, aber gar kein Takt anliegt läuft die
Kiste natürlich gar nicht. Daher poste/beschreibe mal Deinen Aufbau und
versuch mal, die Fuse-Einstellungen auszulesen.Man kann man sich ganz
schell aussperren, wenn man den falschen Oszilator-Typ einstellt. Ist
mir auch schon vorgekommen. Es gibt dann die Möglichkeit den AVR über
ein sauberes Rechtecksignal wiederzubeleben. Hier
http://www.klaus-leidinger.de/mp/Mikrocontroller/meinetools.html#Preserver
findest Du etwas genauer beschrieben, was "Lötlack1" gemeint hat.
Über die Problematik von
"nicht-ganz-standardonformen-Laptop-Signalpegeln" gibts auch jede Menge
Infos. Betreibst Du den Laptop am Netz oder nur mit Batterie?
Also dann erst mal danke an die Poster.
Der ATMega "sollte" fabrikneu sein, also im Laden gekauft, und
begutachtet das er keine Kratzer an den Beinchen hat. Hier kommt das
hiesige, wieter oben beschriebene Problem zum tragen. Hier gibt es nur
Händler meines Misstrauens.
Schaltplan vom Programmer :
http://www.lancos.com/e2p/betterSTK200.gif
allerdings nur mit U1, D1 und R14,
Die anderen Leitungen sind direkt ohne R's verbunden, da das Notebook
nur
3.1V Pegel am Parallelport rauslässt.
den ATMega dann auf einem Steckbrett
Wie schon erwähnt mit 3V
3V an Pin7, Pin20
GND an Pin8, Pin22
100nF Pin7-Pin8, Pin20-Pin22, Pin21-Pin22
R100k Pin7-Pin1
MOSI, MISO, SCK, RST, GND mit denen des Programmers verbunden.
Soweit dazu.
"versuch mal, die Fuse-Einstellungen auszulesen"
weiter oben schon beschrieben. Pony sagt alle Kästchen leer
avrdude sagt ff
bis auf
>> read lock
3f
vielleicht ist das das Problem?
@Niels
sorry, nicht direkt, ich hatte bei pony auf der Seite was zu diesem
Problem gelesen, wo die dann vorgeschlagen hatten in der .ini einige
delay ... Werte höher zu setzen. Was aber nicht von Erfolg gekrönt war.
Vielleicht war ich auch zu zaghaft.
Wenn ich mir die MOSI Leitung auf dem Oszi ansehe beim lesen und
schreiben dann ist pony um vieles langsamer als avrdude.
Aber ich mach das jetzt mal mit avrdude, wie von Dir beschrieben.
Ju
Mir aber nicht, weil ich den Pullup R14 nicht berücksichtigt habe. Daher
hatte ich das Posting von eben wieder zur Kontrolle (in Ruhe) wieder
rausgenommen. Nachdem du dich darauf beziehst, hier ist es:
---
Bei AVR-Vcc 3V vom Targetboard kommt am HC244 über die Diode noch ca.
HC244-Vcc 2.3V an.
Dadurch liegen die HIGH Pegel Voh am Ausgang des HC244 bei ca. 2.2V
aber nur wenn der Strom an dem Output-Pin gering (paar µA!) ist. Der
Eingang des AVR erkennt HIGH Vih bei 0.7V*Vcc, d.h. ab 2.1V. Du
navigierst aber gerade mal 0.1V über dem garantierten Minimalwert.
Welche Spannungswerte hast du an den I/O-Pins vom AVR?
Setz die Widerstände mal rein, insbesondere die Serienwiderstände R9 bis
R11, in der Hoffnung den Outputstrom am HC244 runterzuquetschen und den
Spannungsdrop Vcc minus Voh zu senken. Welche Spannungswerte hast du an
jetzt den I/O-Pins vom AVR?
Eine Alternative wäre, vom Targetboard her eine höhere AVR-Vcc zu
benutzen, die dann auch am HC244 ankommt. Die Zahlen von oben wären dann
AVR-Vcc 5V => HC244-Vcc 4.3V => HC244-Voh 4-4.2V => AVR-Vih ab 3.5V,
d.h. fette 0.5V Spielraum! Spricht was dagegen das Targetboard zum ISP
Programmieren z.B. auf 5V zu schalten, was ist sonst noch drauf?
ADD: Den LPT würde ich auf jeden Fall über die Serienwiderstände vor zu
hohem Strom Schützen!
Oder ersetze die Diode durch eine Schottky-Diode, d.h. eine mit
geringerer Durchlassspannung, um HC244-Vcc anzuheben.
Oder versorge den ISP (HC244) durch ein eigenes Netzteil mit einem
AVR-Vcc ähnlichen Spannungswert (Batterie, USB?). Dann aber dafür
sorgen, dass sich Vcc vom ISP und vom Targetboard nicht am ISP Stecker
begegnen (Jumper).
die Woche leider zu nichts gekommen, also mal die letzten news.
Also das Problem scheint am 244 Pin 19 zu liegen.
Der HC244 mit 3V betrieben bzw. 2.2V hinter der Diode, steht der Pin 19
auf 2.2V, stecke ich den Parallelport an, geht die Spannung runter auf
1.6V wenn das Parallelport bit nicht gesetzt ist. Setze ich das bit dann
geht der pin 19 auf 3.1V.
Das Datenblatt vom HC244 meint um da Vil zu erkennen sollen da max. 0.5V
ankommen.
Also würde ich am AVR nie einen reset hinbekommen.
Da ist doch was nicht so wie es sein soll, oder hab ich einen
Denkfehler?
Hallo,
auch wenn die Meinungen auseinandergehen, ich beutze auch PonyProg
zusammen mit einem STK200-Dongle.
Auch ein Notebook-Parallelport sollte TTL-Pegel liefern, das erwartet
ein Drucker schließlich auch. Der 74HC244 erwartet normalerweise
CMOS-Pegel, allerdings sind das bei 5V Ub auch nur 3V für H, die sollte
auch ein Notebook zustande bringen.
Wenn Pony -24 meldet, macht es wenig Sinn, mit "ignorieren"
weiterzumachen...
Diese Funktion dient NUR dazu, ein unbekanntes Device, daß Pony NICHT
kennt, vielleicht doch mit einer anderen Einstellunh zu zu
programmieren.
Pony auch unbedingt auf den richtigen AVR einstellen, AVR-Auto macht
meist, was es will, nicht was es soll.
Welche Schaltung hast Du benutzt? Die obere mit den Schutzwiderständen
funktioniert meist nicht, weil die Signale unsauber werden, Original ist
die untere ohne die Längswiderstände.
Den 244 direkt an den Par-Portstecker bauen, KEINE Kabel
dazwischenbenutzen, die IPS-Leitung zum AVR kann dann durchaus 1m sein,
möglichst Flachbandkabe,. möglichst die 10pol. STK200-Version benutzen,
da ist dann jede 2. Leitung GND oder VCC als Schirm.
Meine Minimal-Beschaltung am AVR: Alle GND und VCC/AVCC-Anschlüsse
anschließen, dicht am AVR die üblichen 100n zwischen VCC und GND.
Reset nur ein 47n...100n gegen GND.
Pony muß den AVR erkennen, Pony muß die Fuses mit Read auslesen können
und die Haken müssen dem des AVR Lieferzustand entsprechen.
Kalibrierung von Pony nicht vergessen, Interface Parallelport, AVR ISP
I/O, passender LPT (normalerweise 1), sonst keine Haken.
Probe muß OK liefern, evtl. im BIOS den Port auf Standard setzen (war
bei mir noch nie nötig), unter WinXP soll es mehr Probleme geben als
unter W2000/W98 (kann ich so auch nicht bestätigen), älterer Recher
gehen besser als neuere (eben wegen der Pegelverhältnisse).
Gruß aus Berlin
Michael