ATTiny 2313-20PU und 2313A-PU

#7985761
Lesenswert?

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
#7985950
Lesenswert?

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.

(Firma: 1984now) #7986061
Lesenswert?

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...

#7986806
Lesenswert?

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.

#7986864
Lesenswert?

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

#7986909
Lesenswert?

... 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.

Gast #7986931
Lesenswert?

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.

#7987007
Lesenswert?

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.

#7987008
Lesenswert?

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.
(Firma: 1984now) #7987227
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren