Hi, vor einiger Zeit hatte ich in der Bucht einige Tiny85 erstanden. Leider ließen sie sich nicht programmieren. Also flugs den Fuse resetter aus der Schublade geholt (nach http://www.simpleavr.com/avr/hvsp-fuse-resetter) und versucht die Tinys wieder zu beleben. Leider erfolglos. Die Fuses sind 52 5E FE (L, H, E) und lassen sich mit den Fuse resetter nicht ändern. (RSTDISBL und SELFPRGEN sind gesetzt) Der Fuse resetter hat bis jetzt immer funktioniert. Allerdings hatte ich mit SELFPRGEN bis jetzt noch nicht herumgespielt. Gibt es da einen Trick oder wurde mir da schlicht Mist verkauft? An den Chips ist nichts Auffällliges zu entdecken. Date code ist 1715.
Manchmal hilft es, den Reset-Pin fest mit GND zu verbinden, anstatt mit dem Ausgang des Programmieradapters.
M. K. schrieb: > Und du bist sicher, dass dein HV-Programmer wirklich einwandfrei geht? Ja, nochmal mit einem anderen Tiny aus einer anderen Charge getestet, bei dem ich die Fuses geändert habe. Horst schrieb: > Daran, den ISP-Takt zu senken, hast Du aber gedacht? Das war das erste bevor ich den Resetter aus dem Schrank geholt habe. (bis -B 100) Stefan U. schrieb: > Manchmal hilft es, den Reset-Pin fest mit GND zu verbinden, anstatt mit > dem Ausgang des Programmieradapters. Der Adapter hat noch nie Probleme gehabt. Ich habe auch noch einen anderen ausgetestet (alles USBASP). Der Fuse resetter hat ein Display mit dem ich die aktuellen Fuses überprüfen kann. Das ist also nicht vom Programmieradapter abhängig (Der hier sowieso nicht mehr funktioniert, da RSTDISBL gesetzt ist).
> Der Adapter hat noch nie Probleme gehabt.
Ist schon klar, aber wenn der µC nicht wirklich neu ist ist könnte es
sein, dass er ein Programm ausführt welches so gründlich abschmiert,
dass danach die ISP Schnittstelle blockiert. Mir ist das schon einmal
passiert.
Durch das "festhalten" der Reset Leitung verhindert man, dass das
Programm startet.
Stefan U. schrieb: >> Der Adapter hat noch nie Probleme gehabt. > > Ist schon klar, aber wenn der µC nicht wirklich neu ist ist könnte es > sein, dass er ein Programm ausführt welches so gründlich abschmiert, > dass danach die ISP Schnittstelle blockiert. Mir ist das schon einmal > passiert. > > Durch das "festhalten" der Reset Leitung verhindert man, dass das > Programm startet. Die uC waren alle neu! Frisch aus dem Reel. (5x) Und ich rede hier auch von HV Programmierung des Fuse resetters, nicht mehr von der normalen ISP Schnittstelle. Da liegt Reset auf +12V, nicht auf GND.
Andreas B. schrieb: > Ja, nochmal mit einem anderen Tiny aus einer anderen Charge getestet, > bei dem ich die Fuses geändert habe. War bei dem auch der Reset disable? Ansonsten würde ich die Charge einfach reklamieren oder ist das nicht möglich?
Andreas B. schrieb: > (RSTDISBL und SELFPRGEN sind gesetzt) Werkseinstellung für die Digispark. Evtl welche für die Serie bekommen.... Andreas B. schrieb: > Der Fuse resetter hat bis jetzt immer funktioniert. Bei mir auch. Wüste auch nicht, was dem im Wege stehen könnte. Würde mal sage: Ein Garantiefall. // --- Stefan U. schrieb: > Durch das "festhalten" der Reset Leitung verhindert man, dass das > Programm startet. Wie gesagt, macht beim HV Programmer keinen Sinn, da 12V auf den Reset gegeben wird. Und wenn, wie hier RSTDISBL aktiviert ist, dann gibts keinen Reset Pin mehr. Dann ist dein Plan wirkungslos.
Andreas B. schrieb: > Horst schrieb: >> Daran, den ISP-Takt zu senken, hast Du aber gedacht? > > Das war das erste bevor ich den Resetter aus dem Schrank geholt habe. > (bis -B 100) Im HVSP ist der interne Takt egal. In HVSP muß die Taktperiode <220ns sein, d.h. alles unter 4MHz ist o.k. Es kann sein, daß da eine gemeine Firmware eingebrannt wurde, d.h. minimale Startupzeit und PB5 auf low. In dem Fall VCC zuerst nur auf 1,0V setzen: "1. Set Prog_enable pins listed in Table 20-14 to “000”, RESET pin and VCC to 0V. 2. Apply 4.5 - 5.5V between VCC and GND. 3. Monitor VCC, and as soon as VCC reaches 0.9 - 1.1V, apply 11.5 - 12.5V to RESET. 4. Keep the Prog_enable pins unchanged for at least 10 μs after the High-voltage has been applied to ensure the Prog_enable Signature has been latched. 5. Release the Prog_enable[2] pin to avoid drive contention on the Prog_enable[2]/SDO pin. 6. Wait until VCC actually reaches 4.5 - 5.5V before giving any serial instructions on SDI/SII."
M. K. schrieb: > War bei dem auch der Reset disable? Darum geht es ja bei dem Fuse resetter. Der kann den Reset disable noralwerweise per HV programming zurücksetzen aber eben bei diesen nicht. Wie schon erwähnt: RSTDISBL und SELFPRGEN sind gesetzt. > Ansonsten würde ich die Charge > einfach reklamieren oder ist das nicht möglich? Leider zu spät. Die fliegen schon 3 Monate bei mir rum.
Andreas B. schrieb: > Leider zu spät. Die fliegen schon 3 Monate bei mir rum. Probiere mal den Trick, den Peter genannt hat. Ich drücke dir die Daumen dass das klappt ;)
Leider kann ich nicht weiterhelfen, nur eine Information geben: Ein ATtiny85-20PU von 1706, auf obige Fuse-bytes (52 5E FE) gesetzt, wird von meinem Selbstbau-HV-Programmiergerät ganz problemlos auf 62 DF FE gesetzt. (Wollte ich ihm auch geraten haben...)
> ... gemeine Firmware ...
Klingt pausibel; andererseits beträgt bei L=52 die Start-up Time 4 ms,
sollte das nicht auch für dieses simpleavr-Teil reichen?
Angehängte Dateien:
-
FuseResetter.png
1,8 KB
Das Problem an Peters Lösung (alternative 2 im DB) ist, daß mal auf die 0.9-1V V warten soll. Dazu müßte man: 1. Eine ADC am tiny2313 haben 2. Den Tiny2313 umprogrammieren. Das ist dummerweise etwas schwierig, weil ich das ganze Dingens auf ein Lochraster gelötet habe und oben drüber noch das Display aufgelötet ist. Daher habe ich mich jetzt mal dran gemacht, mit dem Oszi zu schauen, was der Fuse resetter so treibt. Gelb ist Reset (12V) und blau ist Vcc. Man sieht daß die Spanung sehr schnell ansteigt, so daẞ Algo 2 eigentlich nicht notwendig sein sollte. Das einzige was nicht gut aussieht, ist der Spannungsverlauf davor. Die gleiche Leitung wird ja vorher für die Displayansteuerung verwendet. Da sollte evt. noch eine Pause vorher reingemacht werden bevor man mit dem Programmieren anfängt. Mal in die SW geschaut und siehe da: In Zeile 456 war doch tatsächlich mal eine Pause drin. Warum die auskommentiert wurde, weiß der Geier. 50ms wären ja etwas viel aber 1ms hätte ich da jetzt schon reingemacht. Ich werde den Programmer jetzt nochmal auf ein Steckbrett aufbauen und die Pause wieder einkommentieren. Mal schauen was er dann macht. Eigentlich ist es den Aufwand wg. 9 Tinys nicht wert, aber ich will es jetzt wissen.
Eines ist mir nicht klar: woher kennen Sie die Werte der Fuse-Bytes? Vom simpleavr-Resetter? In diesem Fall müsste der Einstieg in den HV-Modus (in der Routine read-chip) doch funktionieren, oder?
Timing mit der geänderten SW nochmal mit einen weiteren Aufbau auf dem Steckbrett überprüft: Sieht sehr gut aus. Vcc ist jetzt sauber auf GND bevor es losgeht. Anstiegsrate Vcc < 2us. Ebenso 12V an Reset. (der 40us später kommt). Auch das Timing für die Programmierung is ok. Sieht so aus, als wären diese Tinys ein Fall für die Tonne.
S. Landolt schrieb: > Eines ist mir nicht klar: woher kennen Sie die Werte der Fuse-Bytes? Vom > simpleavr-Resetter? Ja, der Resetter zeigt das an. Schau doch mal den Link oben an. Der hat dafür 4 7-Segmentanzeigen oben drauf. Prima Teil. Nachbau empfehlenswert. > In diesem Fall müsste der Einstieg in den HV-Modus > (in der Routine read-chip) doch funktionieren, oder? Tja, das ist ja gerade das Problem ;-) Programmierung läuft und danach das gleiche wie davor. Ich habe auch gerade noch mal einen anderen Tiny (meinen letzten! Mutig, nicht?) auf 52 5E FE gefust. War kein Problem, den wieder zurückzusetzen. (mit den Resetter natürlich)
Bevor wir uns endgültig geschlagen geben, eine letzte Frage: haben Sie das immer mit demselben Chip aus dieser zweifelhaften Charge probiert, oder auch mal einen zweiten und dritten genommen?
S. Landolt schrieb: > Bevor wir uns endgültig geschlagen geben, eine letzte Frage: haben Sie > das immer mit demselben Chip aus dieser zweifelhaften Charge probiert, > oder auch mal einen zweiten und dritten genommen? Ich habe vier aus diesem Reel genommen. Die anderen 5 sind noch verpackt. Ich probiere die anderen 5 auch noch mal, aber ich glaube da nicht mehr dran. Nils N. schrieb: > Benutzt du auch einen originalen Programierer..? Nein. Ich hatte noch nie Veranlassung dafür mehr Geld auszugeben. Die USPASP haben bei immer alles getan was sie sollten. Ein Pollin Funk Eva Board und ein AVR910 Nachbau habe ich noch aus der Steinzeit, aber die beherrschen beide keine HV Programmierung.
Er tut, vorher noch programmiert, beim zweiten Hinschaun nicht mehr mit, und sagt, dieweil sich's Byte verliert: "I quit". in memoriam KLEN
An den 52 5E FE lag es aber nicht. Ich habe den Tiny anschliessend problemlos programmieren können.
Kann es sein, dass die Chips gesperrt sind, also LB1/2 im Lock-Bit-Byte gesetzt? "... The Fuse bits are locked in both Serial and High-voltage Programming mode."
In diesem Fall müsste man also in chip_read vor dem "write fuse low bits" ein chip-erase einbauen.
Hmm, das erscheint plausibel. Jetzt muß ich mal schauen wie ich das in die SW hineinbekomme. Den Befehlsaufbau habe ich noch nicht so ganz kapiert.
... Da sind wir schon zu zweit, zumal meine C-Kenntnisse nur rudimentär
sind.
Aber wie wäre es mit Folgendem (nur für ATtiny_5, also ohne
Typ-Unterscheidungen), in chip_read unmittelbar nach 'if (release_reset)
{':1 | cmd[0] = 0x80; |
2 | cmd[2] = 0x00; |
3 | cmd[3] = 0x64; |
4 | cmd[5] = 0x6C; |
5 | hv_cmd(cmd, 3); _delay_ms(50); |
Das war es gewesen. :-) (mit hv_cmd(cmd,4)) Das Problem war mehr die Deutung der Tabelle 20.16, weniger C an sich. Danke Dir! Warum der Kerl daran nicht gedacht hat. Ich bin nicht auf die Idee gekommen, daß der Chip erase da nicht mit drin ist. Ich werde jetzt noch mal die Fallunterscheidungen einbauen. Bin ich eigentlich zu doof oder gibt es da nichts wie man mit den Autor des simpleavr fuse resetters in Kontakt treten kann? Sorry nochmal für Deinen verstorbenen Tiny.
Hier nochmal der vollständige Source. Es gibt keine Fallunterscheidungen. Die betroffenen Tinys haben alle den gleichen Chip erase command. Es war übrigens doch hv_cmd(cmd,3). War Blödsinn was ich da vorher geschrieben habe.
> Warum der Kerl daran nicht gedacht hat...
Ich gebe zu, dass ich bei meinem eigenen Gerät auch nicht daran gedacht
hatte. Muss zur Ehrenrettung allerdings hinzufügen, dass sich der
Zustand 'RSTDISBL gelockt' mit dem normalen seriellen Modus ja gar nicht
herstellen lässt, schließlich ist nur das eine oder andere möglich;
beides geht nur im HV-Modus, und diesen nutze ich sonst nie.
(Nur am Rande: das ist ein Missverständnis, hier bei mir ist nichts
'gestorben'. Ich erlaube mir ab&zu, bei besonderen Gelegenheiten und
mehr für mich selbst, an meinen verstorbenen Numerikprofessor zu
erinnern, der unter dem Pseudonym KLEN Gedichte, einzelne Verse und
Schüttelreime verfasste, indem ich ihn zitiere)
Na, dann ist ja alles gut. ;-) Ich habe es übrigens geschafft, den "Original" Fuse resetter umzuprogrammieren, obwohl da noch das 7-Segment Display mit dran hing. (Das Display ist über den Tiny2313 gelötet). Da das Ganze im Schnellverfahren auf eine Lochrasterplatine gelötet wurde, hätte ich mir beim Auslöten das Board ziemlich versaut. So habe ich einfach einen ISP Anschluss (so was ähnliches jedenfalls) mir draufgelötet und fertig. Gut zu wissen, daß man so noch Optionen hat, ggf. in die SW noch was einzufügen.
Andreas B. schrieb: > Das war es gewesen. :-) Ja, die Lockbits verriegeln auch die Fuses, ein Erase ist also Pflicht. Sonst könnte man ja das Debugwire/JTAG enablen und hätte so ne Backdoor zum Auslesen.
:
Bearbeitet durch User
Andreas B. schrieb: > Das war es gewesen. :-) Danke! Ich habe in diesem Thread was gelernt. 1. Dass man sich doch noch etwas gründlicher abhängen kann, als ich erwartet habe. 2. Dass mein HV FuseBitDoctor den offensichtlich manchmal notwendigen Chip Erase macht. (und ich somit kein Chance hatte den Fehler zu reproduzieren)
Arduino F. schrieb: > Dass mein HV FuseBitDoctor den offensichtlich manchmal notwendigen > Chip Erase macht. (und ich somit kein Chance hatte den Fehler zu > reproduzieren) Es wäre mal interessant, in diese FW hineinzuschauen. Ich will auch noch was lernen. ;-) Welchen Fuse doctor hast Du denn?
Hach ... Ist schon ein paar Jahre her. Und habe auch nur eine vorhandene *.hex geflashed. Aber das Board, ist exakt dieses, ebay: 152277809800
Habe das Projekt hier gefunden: http://community.atmel.com/projects/atmega-fusebit-doctor-hvpphvsp Leider auch nur die hex drin. So etwas baue ich prinzipiell nicht nach. (Genauso wenig wie ich Windows benutze. Hab so meine Prinzipien. ;-) ) Hast Du auch mal den Versuch gemacht, dich komplett mit den Lock Bits auszusperren?
Andreas B. schrieb: > Hast Du auch mal den Versuch gemacht, dich komplett mit den Lock Bits > auszusperren? Ja, das habe ich gemacht. Die Lockbits auf 0xfc gesetzt Für diesen Zweck gibts übrigens extra einen "Erase Allow" Jumper auf dem Board. Welcher auch das erwartete Verhalten zeigt. Ohne Jumper versagt das Fuse Reseting bei gesetzten Lock Bits. Andreas B. schrieb: > So etwas baue ich prinzipiell nicht nach. Ich ahne was du meinst. Aber das Board selber ist gut genug dokumentiert, so dass man jederzeit eine eigene Firmware schreiben kann. War nur bisher nicht nötig. Damals war es zwingend nötig eine kleine Schachtel voll mit ATMegas wieder zu beleben. Oder ein paar Dutzend neue zu kaufen. Die Zeit war knapp, also war eine solche 3/4 Fertig Lösung angemessen. Übrigens, wenn ich Motorrad fahren will, dann baue ich den Motor auch nicht selbst. Vielleicht dengel ich mir einen Tank, wenns schöner als das Original werden soll. Aber im Grunde, auch das eher nicht.
Arduino F. schrieb: > Übrigens, wenn ich Motorrad fahren will, dann baue ich den Motor auch > nicht selbst. Vielleicht dengel ich mir einen Tank, wenns schöner als > das Original werden soll. > Aber im Grunde, auch das eher nicht. Das mache ich auch nicht. Aber wie Du siehst, hätten wir den Fehler nie gefunden wenn ich nur die hex gehabt hätte.
Andreas B. schrieb: > Aber wie Du siehst, hätten wir den Fehler nie > gefunden wenn ich nur die hex gehabt hätte. Dann wärst du gar nicht auf das Problem gestoßen! OK, zumindest ICH wäre da nicht drauf gestoßen... Du schon, da deiner nicht "perfekt" genug war. ;-) Das unterscheidet "gute Werkzeuge" von Bastelkram. ;-) Ach, was solls.... Ich habe was gelernt, du auch, deine Dinger tuns wieder, und damit ist doch alles gut. Sogar dein Code auf deinem HV Dingen ist jetzt besser. Alles in allem: Ein voller Erfolg.
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.