Hallo, ich brauche einfach nur eine 4-Augen-Prüfung, nicht dass ich was übersehe. Für ein Projekt möchte ich einen ATTiny2313 einsetzen, habe paar davon und die Anzahl Ports reicht. Wollte nur meine Tool-Chain testen, und habe nach langem Suchen (auch in der Chip-Kiste) folgende Situation: Zum Testen lese ich nur den Chip-Inhalt mit dem avrdude aus (Aufruf im shell-script). (1) mit dem 2313-20PU bekomme ich keine Fehlermeldung, nur den Hinweis, dass der Chip leer ist, Die Signatur identifiziert ihn korrekt. (2) mit allen (5 Stück) 2313A-PU bekomme ich die Meldung: avrdude: Device signature = 0x000000 avrdude: Yikes! Invalid device signature. (3) ich habe in meinem Setup auch mit 25, 85 gespielt, jeweils problemlos. Der 2313A-PU ist ja der Nachfolger des 2313, sollte lt. Doku identisch anzusprechen sein. Ich schliesse daraus, dass die 2313A-PU defekt sind. Oder übersehe ich etwas? Danke und Groß Rene Edit: Ich benutze einen Arduino-UNO als ISP, habe das mit einem Original und einem Clone betestet, identische Ergebnisse
:
Bearbeitet durch User
Rene Z. schrieb: > Ich schliesse daraus, dass die 2313A-PU defekt sind. Vielleicht auch nur falsch rum reingesteckt? Zeig' doch mal ein Foto der beiden Packages im direkten Vergleich.
Rene Z. schrieb: > Ich schliesse daraus, dass die 2313A-PU defekt sind. Oder übersehe ich > etwas? Eventuell musst du die Taktfrequenz der ISP Schnittstelle (auf wemiger als 250 kHz) reduzieren. Eventuell sind die Chips gebraucht und für eine externe Taktquelle oder Quarz konfiguriert.
Nemopuk schrieb: > Eventuell musst du die Taktfrequenz der ISP Schnittstelle (auf wemiger > als 250 kHz) reduzieren. Im Extremfall auf weniger als 4kHz! > Eventuell sind die Chips gebraucht und für eine externe Taktquelle oder > Quarz konfiguriert. Oszillator an Pin 5 anschließen.
Beim Vergleich der Datenblätter fällt auf: ab Werk steht das Low-Fuse-Byte beim 2313 auf 0x64, beim 2313A jedoch auf 0x62. Folglich läuft Letzterer nur mit 4/8 MHz, er darf also mit maximal 125 kHz angesprochen werden.
Hallo, vielen Dank für die Tipps. Ich kann ausschliessen, dass ich den verkehrt gesockelt habe, der Punkt für Pin1 ist doch zu auffällig, und ich müsste mich immer vertan haben. Zu den Taktraten: Ich brenne ja mit dem avrdude, da finde ich keinen Schalter, mit dem ich das beeinflussen kann. Im Boards.txt und der avrdude.conf datei finde ich keine Unterscheidung zwischen den beiden. Habt ihr einen Tipp, wo ich fündig werden kann? Das mit dem Oszillator an P5 kann ich mal versuchen, ich habe die Dinger aber als Neu gekauft.
Rene Z. schrieb: > Zu den Taktraten: Ich brenne ja mit dem avrdude, da finde ich keinen > Schalter, mit dem ich das beeinflussen kann. -b > ich habe die Dinger > aber als Neu gekauft. Wo?
Angehängte Dateien:
-
ATtiny2313A.png
34 KB
S. L. schrieb: > beim 2313A jedoch auf 0x62 Ein Fehler im Datenblatt. Weiter vorn steht es richtig.
Rene Z. schrieb: > Zu den Taktraten: Ich brenne ja mit dem avrdude, da finde ich keinen > Schalter, mit dem ich das beeinflussen kann. -B20 -b ist für die Baudrate des COM Port, also hier nicht hilfreich.
:
Bearbeitet durch User
Ich habe die Einstellungen bei der Arduino-IDE geklaut. Da stand 19200. Hatte es auch mit 9600 ohne Erfolg probiert. Zu der Quelle: hm... aus der Bucht...
Nemopuk schrieb: > Rene Z. schrieb: >> Zu den Taktraten: Ich brenne ja mit dem avrdude, da finde ich keinen >> Schalter, mit dem ich das beeinflussen kann. > > -B20 > > -b ist für die Baudrate des COM Port, also hier nicht hilfreich. Stimmt, Groß/Klein-Schreibung ist hier ja relevant.
Rene Z. schrieb: > Zu der Quelle: hm... aus der Bucht... Lehrgeld.. Kauf sowas bei seriösen Händlern. Die Bucht ist es nicht und ALI schon garnicht.
Rene Z. schrieb: > Zu der Quelle: hm... aus der Bucht... Na, dann zeig mal. Das werden einfach Fälschungen sein.
Rene Z. schrieb: > Ich habe die Einstellungen bei der Arduino-IDE geklaut. Da stand 19200. > Hatte es auch mit 9600 ohne Erfolg probiert. Falscher Parameter. Wie gesagt hast du damit die Baudrate des COM Ports geändert, nicht die Bitrate der ISP Schnittstelle.
H. H. schrieb: > Rene Z. schrieb: >> Zu der Quelle: hm... aus der Bucht... > > Na, dann zeig mal. Das werden einfach Fälschungen sein. Komplett disfunktionale Fälschungen kommen schonmal vor, sind aber doch eher selten. Vor allem nicht bei noch produzierten Chips. So jedenfalls meine Erfahrung. Ist aber egal, der TO ist eh' ein Troll. So wie der sich wehrt, Fotos herauszurücken, dazu das Datum der Nutzeranmeldung...
Erst mal Danke an alle, und Nein, ich würde mich nicht als Troll bezeichnen. Lese hier schon lange (mit Pausen) mit, aber zum Frage stellen musste ich mich anmelden. Und zu den Fotos, der Aufdruck ist recht schwach und ob es was bringt? Die ursprüngliche Frage dazu war ja, zu sehen, ob ich den verpolt eingesetzt habe. Dazu das Bild. Meine ursprüngliche Frage war ja auch, wenn der eine es tut, sollte dann nicht der andere es im gleichen Setup tun??? BTW: Habe verschiedene Baudraten probiert, immer das gleiche Ergebnis.
Rene Z. schrieb: > BTW: Habe verschiedene Baudraten probiert, immer das gleiche Ergebnis. Zum vierten mal: Die Baudrate ist der falsche Parameter! Sie hat keinen Effekt auf die ISP Taktrate.
Rene Z. schrieb: > Und zu den Fotos, der Aufdruck ist recht schwach und ob es was bringt? Kannst ruhig noch wochenlang rumprobieren...
Rene Z. schrieb: > Meine ursprüngliche Frage war ja auch, wenn der eine es tut, sollte dann > nicht der andere es im gleichen Setup tun??? Nein, weil gerade in CN auch gebrauchte Chips im Umlauf sind, die dann niedrige Taktraten erfordern > BTW: Habe verschiedene Baudraten probiert, immer das gleiche Ergebnis. Du sollst auch nicht alle Bitclocks (nicht Baudraten!) probieren, sondern einfach mal eine langsame setzen (B GROSS), z.B. -B 16
> ... gebrauchte Chips im Umlauf ...
Für diesen Fall und vorausgesetzt, es ist im High-Fuse-Byte nicht
RSTDISBL gesetzt, könnte ich ein Hilfsprogramm in Form einer Hex-Datei
für den (offenbar vorhandenen) ATtiny85 als Master bereitstellen; führt
auf dem Zielcontroller ein Chip-Erase aus und setzt das Low-Fuse-Byte
auf Werkseinstellung.
Wer nicht viel rumhexen will, nimmt AVRStudio und STK500. "Meine" AVRs habe ich alle mit ISP Takt 4 k oder noch "langsamer" geflashed. Eine Sekunde länger macht den Kohl nicht fett. ciao gustav
> ... ISP Takt 4 k oder noch "langsamer" ...
Im Extremfall ist beim ATtiny2313 unter 125 Hz nötig.
S. L. schrieb: >> ... ISP Takt 4 k oder noch "langsamer" ... > > Im Extremfall ist beim ATtiny2313 unter 125 Hz nötig. Welcher Extremfall soll das denn sein?
> Welcher Extremfall soll das denn sein?
Hängt von der Programmierumgebung ab; '128 kHz Internal Oscillator' mit
einem Programm, in welchem der Clock-Prescaler auf 256 gesetzt ist.
... steht etwas überdeckt da: höchstens 0,25 des "Systemclocks" ciao gustav
S. L. schrieb: >> Welcher Extremfall soll das denn sein? > > Hängt von der Programmierumgebung ab; '128 kHz Internal Oscillator' mit > einem Programm, in welchem der Clock-Prescaler auf 256 gesetzt ist. Wenn man den über ISP programmiert, dann läuft in der Zeit kein Programm das das Prescale-Register ändern könnte.
an H.H.: Es ist so. Und wurde hier im Forum vor Längerem mehrfach und ausführlich diskutiert - war wohl vor Ihrer Zeit.
"As already suspected, the clock remains at the scaled (lower) value even after the reset." https://lists.nongnu.org/archive/html/avrdude-dev/2013-09/msg00104.html
Mario M. schrieb: > "As already suspected, the clock remains > at the scaled (lower) value even after the reset." > > https://lists.nongnu.org/archive/html/avrdude-dev/2013-09/msg00104.html Aha, also schlampige Dokumentation von Atmel. Und bisher hatte wohl niemand Lust, das im AVRdude zu ergänzen.
H. H. schrieb: > Wenn man den über ISP programmiert, dann läuft in der Zeit kein Programm > das das Prescale-Register ändern könnte. Doch. Beim Anlegen der Stromversorgung startet das installierte Programm und stellt (optional) den Taktteiler ein. Wenn danach der Programmiervorgang via ISP mittels Reset startet, läuft die CPU während dessen immer noch mit der eingestellten Taktfrequenz. Die Vorgabe durch die Fuse wird erst beim Verlassen des Programmiervorganges wirksam, also nach der steigenden Flanke des Reset Signals. Workaround: Verhindern dass das Programm startet, indem man Reset ständig auf GND zieht schon bevor die Stromversorgung angelegt wird. Damit kommt allerdings nicht jeder Programmieradapter zurecht.
Angehängte Dateien:
H. H. schrieb: > Aha, also schlampige Dokumentation von Atmel. Es ist dokumentiert. Wobei ich das auch erst verzögert begriffen habe, als ich die Fuses auf duesen Extremfall einstellte und mein Programmieradapter nicht so langsam takten konnte (ist lang her und wurde vom Hersteller des Programmieradapters behoben, nachdem ich ihm davon berichtete).
Beitrag #7987011 wurde vom Autor gelöscht.
Nemopuk schrieb: > H. H. schrieb: >> Aha, also schlampige Dokumentation von Atmel. > > Es ist dokumentiert. Nicht wirklich. Der markierte Text beschreibt in keinster Weise den Sachverhalt, dass das CLKPR-Register erst zum Ende des Resets den dokumentierten Reset-Inhalt bekommt, während des Resets also weiterhin den zuletzt konfigurierten Zustand behält. Das ist ein zumindest überrschendes Verhalten, denn darin unterscheidet sich dieses Register von den meisten anderen Registern, bei denen der dokumentierte initiale Inhalt zu Beginn des Resets gesetzt wird.
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.