Ich wollte gerade bei einem nagelneuen ATtiny2313 mit Datecode 0530 die Fusebits auf externen Quarz umstellen, als ich die Fehlermeldung "fehlgeschlagen" bekam. Das war das erste mal das ich diesen Fehler hatte ! Nach längerer Fehlersuche (es ist ja nie auszuschließen, dass der Fehler an meinem Programmiergerät liegt) kam ich zu dem Ergebnis, das der Fehler eindeutig am AVR liegt. Ein älterer tiny2313 lässt sich nämlich wunderbar programmieren. Also habe ich den AVR mit Code 0530 mal genauer untersucht: a) Die Fusebits stimmen nicht mit dem Wert überein, der im Datenblatt (und normalerweise auch im AVR sein sollte): Alle von den 10 AVRs mit Datecode 0530 die ich habe, haben als Fuse Low Byte 11100010 und nicht 01100100 wie es sein sollte. Der AVR läuft also mit den internen 4MHz anstelle der 8MHz + Teiler durch 8 was er standardmäßig haben sollte. b) Erst nachdem man den AVR mit einem Programm beschreibt (also Chip Erase + Programmieren) kann man die Fuse Bits erfolgreich beschreiben. Das ganze habe ich mit zwei unterschiedlichen PCs und Programmern getestet, es liegt also definitiv am AVR. Was baut Atmel als nächstes an Mist ?
Wieso Atmel? Wo hast Du die Tinys her? Von einem offiziellen Distributor aus einem original verpacktem Tray, oder von einem Einzelteil-Dealer aus dem Internet?
Hallo Benedikt, jetzt ist es dir also auch passiert. siehe: http://www.mikrocontroller.net/forum/read-1-252971.html#new Ich weiss auch nicht, wie Atmel sich das vorstellt. Bei ein paar Controllern ist das nicht schlimm, aber für eine Serienproduktion kann man das vergessen. Gruß Volker
@Volker Stimmt, diesen Thread hatte ich ganz vergessen. Hast du auch das Problem mit dem Fuse Bit schreiben ? Da ja jetzt bestätigt ist, dass das Problem vermutlich direkt von Atmel stammt: Meine tinys waren von Pollin. @Unbekannter Ich kennen niemanden, der zuhause mit uC bastelt und direkt vom größten Distributor Bauteile in tausender Stückzahlen kauft. Aber davon mal abgesehen, auch die einzelnen uC egal ob von Pollin, Reichelt, Conrad, oder sonst wo her müssen funktionieren. Stell dir mal vor du kaufst ein Auto, das nicht funktioniert. Grund: Du bist kein Geschäftskunde der 1000er Stückzahlen kauft, daher bekommst du den Ausschuss, z.B. mit kaputten Bremsen... Bei einigen von den tiny2313 geht mittlerweile der ISP Modus garnichtmehr, keine Ahnung was ich da verstellt habe. Warscheinlich muss ich die mal auf einem STK500 wieder zurechtbiegen. Wie ist das eigentlich mit der Reset Disable Fuse. Kann man sich im ISP Modus damit aussperren ?
Könnte mal jemand diese Datei in einen ATtiny2313 schreiben ? Ich habe mir mit dieser Software bereits 3 ATtiny2313 ruiniert. Nachdem ich diese Software in einen ATtiny2313 geladen habe reagiert der AVR nicht mehr auf den ISP Programmer. Vielleicht betrifft das ja auch nur die AVRs mit Datecode 0530, keine Ahnung. Oder mein Programmer baut Mist, aber das wäre das erste mal seit Jahren. Falls jemand dieses Verhalten bestätigen kann, dann wäre das der erste AVR Virus...
Die Frage nach der Bezugsquelle ist durchaus gerechtfertigt. Grund: Es gibt immer wieder Bauelemente, die für spezielle Großprojekte gefertigt werden. Diese haben auf Wunsch des Großkunden dann z.B. geänderte Fusebits. Wenn dann am Ende Stückzahlen davon übrig bleiben, werden die über diverse Kanäle (aber nicht die Distributoren) verramscht. Gruß, Marcus
Mir ist gerade eingefallen, dass ich in der Schublade noch 5 nagelneue ATTiny2313V-10PU habe. Diese habe ich damals bei ATmel!! als Sample bestellt (wegen der 1.8V). Bin gleich mal hergegangen und habe die Fuse-Bits ausgelesen. Ergebnis: CKSEL3 0 programmed CKSEL2 0 programmed CKSEL1 1 unprogrammed CKSEL0 0 programmed CKDIV8 programmed Sind also auch auf 4Mhz/8 eingestellt, was nicht dem Datenblatt entspricht. Datecode ist 0512 Ohne vorher ein Programm zu flashen kann ich die Fusebits mit Ponyprog jedoch problemlos ändern. Gruß Volker
@Volker Könntest du mal mein Programm bei dir auf den ATTinys ausprobieren ?
Hab gerade die main.hex geflasht, keine Probleme, danach Programm gestartet (keine Ahnung was das Prog macht). Ich hatte zunächst Sorge, dass vielleicht bei deinem Programm ein Portpin auf Ausgang gesetzt wird, der bei meiner Hardware ein Eingang ist, ging aber alles gut. Zur Probe, ob noch alles geht habe ich wieder ein kleines Testprogramm von mit aufgespielt, keinerlei Probleme; meine LEDS haben genau so geblinkt wie sie sollten. Volker
@Benedikt, was kannst du mit dem STK500 den "vermurksten" Controllern entlocken? Volker
Ich besitze keinen STK500, werde mir aber demnächst einen ausleihen. Allerdings ist der STK500 vermutlich noch orginal, d.h. einen tiny2313 kennt das Ding nicht. Daher bastele ich gerade einen HV Programmer.
So, nach stundenlanger Fehlersuche am HV Programmer (der AVR hat einen internen Pullup am Reset, daher braucht man einen stärkeren Pulldown, damit Reset am Anfang auf Low liegt) läuft er endlich. Den Grund für das nichtfunktionieren der FuseBits vor dem ersten Chip Erase habe ich auch gefunden: Beide Lock Bits sind gesetzt... Jetzt muss ich nur herausfinden warum ISP bei den AVRs mit meinem Programm nicht mehr geht.
>Wie ist das eigentlich mit der Reset Disable Fuse. Kann man sich im
ISP
Modus damit aussperren ?
ja kann man, danach geht nur noch HV programmieren
Marian
Ich habe jetzt alle AVRs aus denen ich mich ausgesperrt habe über den HV Modus wieder resettet. Die Fuse Bits waren alle noch OK, warum ich aber ausgesperrt war, keine Ahnung. Jetzt habe ich wenigstens alle AVRs auf die richtigen Standardwerte gesetzt.
Wenn es die Tinys von Pollin waren.. Die waren vorprogrammiert mit dem Programm von deren Fernsteuerbausatz... Löschen müßte reichen
Die aktuellen 2313 von Pollin (Datecode 0601) ist unprogrammiert, so wie es sein soll
Bitte 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.