Hallo, ich glaube, ich lerne nicht aus meinen Fehler. Mittlerweile ist es wohl der 4 ATtiny13, den ich Platt gemacht hab. Dabei habe ich keine FuseBits falsch gesetzt. Ich teste mich gerade an der PWM. Dabei habe ich den Ports PB0-2 (Miso, Mosi, SCK) eine wiederkehrenden Signalausgabe im 10 bis 1000us Takt vorgegeben. Jetzt lassen sich die Prozessor nicht mehr bespielen. Gibt es eine Möglichkeit, den ATtiny noch zu löschen?
Evtl. stört die Schaltung an den Pins den Programmiervorgang. Das Programm selber kann es eigentlich nicht sein. Denn das interessiert während des Programmierens oder eines Reset nicht. Sicher, dass die Fuses stimmen und der Resetpin nicht deaktivert wurde? Carsten
Weil er es nicht macht. Nachdem ich den Quelltext drauf kopiert habe, lässt sich weder an den FuseBits noch am EEprom was auslesen oder hinein schreiben. Ich glaube, dass kommt daher, dass die Pinns so schnell Signale geben und jeder Versuch ihm andere Daten mitzuteilen deshalb fehlschlägt. Der Prozessor als solches funktioniert auch noch, da die gedimmte LED leuchtet immer noch schwach.
Squat *** schrieb: > Ich glaube, dass kommt daher, dass die Pinns so schnell Signale geben > und jeder Versuch ihm andere Daten mitzuteilen deshalb fehlschlägt. Kann nicht sein, weil der Controller beim Programmieren Resettet wird und damit das Programm nicht mehr läuft. Hast du die LED vielleicht ohne Vorwiderstand angeschlossen? Entferne mal die angeschlossene Schaltung und probiers dann nochmal
Ich habe die FuseBits anfangs eingstellt. Da ich nun was anderes mit dem Prozessor machen wollte, habe ich alles gelassen und nur die Software drüber gepackt. Anfangs habe ich nur einen Pin geändert, aber als ich dann zusätzlich die anderen Pins Aufgaben zugeteilt habe, führen diese das Leuchten aus, jedoch kann ich seitdem nichts mehr programmieren. Ich habe an den Pins jeweils einen 4k7 Widerstand und dahinter einen Transitor für die Ansteuerung der LEDs. Und das Lauflicht funktionierte auch immer (ist jedoch viel langsamer).
Was für nen Programmer hast Du denn? Häng mal das Hex-File an. Ich werds dann mal aufspielen und probieren, ob das ISP wirklich tot ist. Setzt Du vielleicht den CPU-Prescaler auf nen sehr langsamen Takt? Dann mußt Du den SPI-Takt auch runtersetzen. Ich glaub, die werden bei nem externen Reset nicht zurück gesetzt. Peter
Hi Squat Wo sind denn die ISP-Leitungen verbunden, zwischen dem µC und dem Widerstand oder zwischen dem Widerstand und dem Transistor? Ich vermute mal zw. Widerstand und Transistor...oder? Es ist besser wenn du die Schaltung einstellst so kann man besser "raten" ;) MfG
Die ISP-Leitungen sind direkt am ATtiny. Ich habe auch bisher ohne Probleme damit programmiert. Ich habe mittlerweile schon 8 dieser Platinen programiert. und nicht nur einmal, da die Software anfangs nicht so passte. Jetzt habe ich diese Platine zweckentfremdet, um statt dem Lauflicht, die LED zu dimmen. Momentan programmiere ich mit dem USB AVR LAB mit dem AVRISPMKII Protokoll. Zum Brennen verwende ich AVR8 Born-O-Mat v2. Zwischenzeitlich hatte ich auch mal mit der Sercon SI-Prog unter PonyProg2000 probiert. Weder die FuseBits noch den Timer habe ich von der Letzten zur jetigen Version geändert. Im Anhang findet Ihr den hex-Datei.
Angehängte Dateien:
-
Schaltplan.PNG
17 KB
Hier noch der Platinenaufbau. Die blauen Kreise zeigen an, wo die Leitungen zum ISP angelötet wurden. Über welchen Widerstand sollte ich den Reset denn dauerhaft herstellen?
Wie mache ich das mit dem Reset-Pin? Wenn ich diesen direkt gegen Masse schalte, startet zwar das Programm auf dem Controller nicht, jedoch kann ich auch so nicht den Prozessor löschen.
Squat *** schrieb: > Momentan programmiere ich mit dem USB AVR LAB mit dem AVRISPMKII > Protokoll. Zum Brennen verwende ich AVR8 Born-O-Mat v2. So, ich habe das Hex reingeladen. Es brennen die LEDs an PB0,1,2 und 4. Wenn man das STK schüttelt, sieht man an PB0,1,2 ne PWM. Ich kann weiterhin über ISP die Signatur lesen und den Flash löschen und programmieren. Keinerlei Probleme. Ich verwende STK500 und AVRStudio. Peter
Squat *** schrieb: > Über welchen Widerstand sollte ich den Reset denn dauerhaft herstellen? Hängt vom Programmer ab. Vom AVR her darfst du RESET direkt mit Masse verbinden. Wenn der Programmer aber selbst RESET auf Plus legen will (und keine Schutzwiderstände hat), dann könnte er dadurch beschädigt werden. Mit so 300...500 Ohm von RESET nach Masse bist du auf der sicheren Seite. Also dann folgende Reihenfolge: - RESET über z.B. 300...500 Ohm auf Masse legen - Programmer anschließen und Versorgungsspannnug für den Tiny13 einschalten - Programmieren Wichtig ist, dass der Tiny13 keine Versorgungsspannung bekommt, solange RESET nicht auf Masse gelegt ist. Somit können nämlich im Programm evtl. gesetzte Clock-Prescaler nicht aktiv werden.
500 Ohm ist vermutlich zu niederohmig für das Programmiergerät. Bei, AVRIISP mkII steht bei Debugwire dabei, dass der Reset Pullup > 10kOhm sein soll (oder so). Aber das mit dem Hard-Reset ist Quatsch. Der Programmer resettet den AVR vor dem Programmieren. Da muss man nichts von Hand resetten.
Ich tippe einfach auf zu hohe ISP Frequenz, stell die mal gaaanz runter und probiers nochmal
Also ich habe es bei zweien schonmal hinbekommen. Irgendwie hatte es was mit dem Reset und meinem Programmer (USB AVR Lab mit AVRISPMKII) zu tun, aber so richtig habe ich es nicht verstanden. Ich habe nochmal die Sercon angeschlossen (unter PonyProg wird er unter SI Prog AVR geführt). Da ich in PonyProg leider keinen ATtiny13 gefunden habe, musste ich auf AVRdude zurückgreifen. Als Befehl habe ich folgendes eingegeben.
1 | avrdude -c ponyser -P com1 -p t13 -U flash:w:test.hex -u |
Während des Vorganges habe ich dann kurz Reset mit Masse verbunden und dann löschte er auch schon den Chip. Da ich als Quelltext eine imaginäre Datei angegeben hatte, brach er ab. Nun kann ich jedoch in gewohnter Weise mit dem AVR USB LAB drauf zugreifen, Fuse lesen und den Tiny beschreiben. Schön, wäre es, wenn wir das Problem vielleicht doch noch genauer aufschlüsseln könnten, damit ich hier nicht mit zwei Programmern arbeiten muss. Außerdem kann das ja nicht der normale Weg sein.
Probiers dochmal mit dem AVRStudio. Wenns damit nicht geht, schreib nen Bugreport an den Entwickler des USB AVR Lab. Peter
Na ich glaube, dass ist der falsche Weg. USB AVR LAB ist ein privater Entwickler Christian Ulrich, der uns Usern die Möglichkeit gegeben hat, mit einem kleinen Tool mehrere Aufgaben zu ermöglichen (STK500V2, AVRISPMKII, JATGICEmkII, OpenOCD, USBasp, Taktgenerator, Oszilloskop, etc.) Naturlich werde ich Ihm davon berichten und hoffen, dass ihm dazu was einfällt, jedoch ist das kein kommerzielles Produkt und so kann ich keine Ansprüche stellen. Mir ging es jedoch eher darum, zu verstehen, welcher technische Hintergrund eventuell dazu geführt hat, dass das Gerät den Dienst verweigert hat. Aber du hast Recht am ehsten sollte ich diese Frage Christian stellen. Wenn doch noch jemand was dazu einfällt, freue ich mich über jeden Ansatz. Ansonsten möchte ich mich bei Allen bedanken.
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.