also ich bin gerade dabei den avr isp etwas aufzubohren und baue ein paar neue funktionen ein. Nun bin ich bei den Lock-bits angekommen und stelle fest, das in dem sourcecode für avr isp v3.7 von klaus leidinger ein bug ist, der u.U. falsche Daten an einen atmega16 oder attiny2313 schicken kann. BRAUCHE DESHALB SO SCHNELL WIE MÖGLICH KONTAKT MIT KLAUS LEIDINGER. ALSO WENN DU DAS LIEST, SCHAU IN DEIN POSTFACH (klaus@mikrocontroller-projekte.de)
ich weiss nicht ich kann auch noch warten und dann sagen, dass es um die lock bits und fuses geht... wenn du schon mal die ausversehen falsch gesetzt hast weisst du ja was für einen ärger es machen kann die wieder weg zu bekommen...
Das es um die Lock und Fusebits geht sagtest du bereits. Aber was genau stimmt da nicht, welche Codezeilen sind problematisch, wie äussert sich der Bug usw. Ich kenn den Sourcecode recht gut und deshalb würd mich interessieren wo der Fehler ist, da ich dort keinen gesehen hatte, vor allem nicht in diesem (relativ simplen) Codeteil. Ärger hatte ich mit Fusebits noch nicht. Ich hab ein STK und einen äquivalenten Nachbau..
und zwar wird scheinbar nur für den tiny26 das richtige format für die lock bits verwendet: 0xAC Ex xx LL für alle anderen wird ein anderes format verwendet (das dem vom s2313 ähnlich ist) wenn man nun die lockbits für einen mega oder tiny2313 schreiben will, wird das falsche format verwendet (folge ist, das an der stelle wo die lock bits stehen sollen nur nullen stehen und damit alle locks aktiviert werden). beim s2313 sind ja (laut datenblatt) die fuses und die lock bits in einem byte zusammen. in der funktion zum 'l' Kommando (ab ca. 1460) da steht auch "Some more different addresses for other devices?" werde am montag die ganzen datenblätter runterladen und schauen, welche von den uC welches format nutzen...
Vielleicht hilft das (Anhang) ja vorerst weiter, habe ich mal irgendwo hier im Forum gefunden. ...
Ansonsten gibts auch eine gute Liste am Ende der Appnote zum STK500 Protokoll. Ich schau mir den Code morgen auch mal an
Salve, also ich lese/schreibe Fusebits nur über das New Universal Command. Klaus scheint im Moment beschäftigt oder auf Reisen zu sein. Habe auch noch keine Antwort auf meinen Patch bekommen (IrDA-Erweiterung für z.B. PalmAVR). :) Mark
@tobi: wo gibts das, oder bin ich einfach zu dumm bei atmel die richtigen appnotes zu finden? @Mark: wie viel braucht das (code) und gibt es da nicht umsetzer (irda <-> rs/ttl) in hw? Evtl. könnte ich das ja in meinen Programmer noch mti einbauen...
@marcel, Du brauchst ja nicht gleich zu schreien (GROSSBUCHSTABEN). ;-) Welches Kommando zum schreiben der Fusebits / Lockbits verwendet wird, bestimmt ja die Programmersoftware, also der Teil der den programmer anspricht. Deshalb gibt es ja mehrere Kommandos für Hfuse, Lfuse, Xfuse und die Lockbits, da seit der Vorstellung der AN910 einige neue Fuses usw. dazugekommen sind. Der Programmierer der Steuersoftware muss sich also überlegen, welches Kommando er verwendet, oder alternativ muss der Firmwareschreiber für alle unterschiedlichen Chips die unterschiedlichen Adressen verwenden. AVRProg z.B. verwendet wie Mark auch das "new universal" (.) Kommando, um jedem Chip auch den richtigen Code in die Fuses zu schreiben. Avrdude macht das glaube ich auch so. Die anderen Fusebit Kommandos kommen zum grossen Teil aus der Application Note 109, bei der typischerweise (Bootloader) der Zielcontroller, und damit auch die Fuse Adressen bekannt sind. Bei den Kommandos für die "neuen" Fusebits steht ganau aus diesem Grund der von Dir beschriebene Kommentar, und in der Beschreibung ein "untested". Mir ist nicht bekannt, welche Software diese Kommandos verwendet. Wenn Du eine Liste der verschiedenen Adressen und dazugehörigen Chips erstellt hast, würde es mich freuen, wenn Du sie veröffentlichst. HTH, viele Grüsse, Klaus
jetzt mal ganz leise: wäre es dann nicht sinnvoller, wenn man das kommando erhält ein '?' zurück zu geben?
"?" bedeutet unbekanntes Kommando, und unbekannt ist es ja nicht. Dann macht es schon mehr Sinn es garnicht zu implementieren. Hast Du denn eine Programmersoftware die diese Kommandos benutzt?
sw: avrprog 1.4 der fehler ist mir nur aufgefallen, weil ich das ding aufgebohrt habe und dadurch an die stelle gekommen bin... also die daten lesen ein 13d ausgeben und nichts weiter machen? dann kann es aber sein, das sich ein nutzer wundert, das nichts passiert... und wie ich die meisten computer-nutzer kenne, hauen die dann nochmal auf den knopf und schicken dann eine schöne mail. also, wenn ich die liste fertig habe, werde ich sie auf meiner seite veröffentlichen, aber dazu brauche ich noch einpaar datenblätter (siehe thread im forum): at90s2333 at90s4413 at90s4434 atmega603 atmega83 attiny10
@Marcel: Gib mir mal deine Mailadresse wegen der alten Datenblätter, sind zu groß fürs Forum (Anhang). ...
Habe auf einer älteren ATMEL-CD gefunden: 2333 4414 (nicht 13) 4434 Tiny10 Die anderen leider nicht. ...
>sw: avrprog 1.4 >der fehler ist mir nur aufgefallen, weil ich das ding aufgebohrt habe >und dadurch an die stelle gekommen bin... avrprog aufgebohrt? Welcher Controller ist eingestellt? (den tiny2313 kennt avrprog ja leider nicht) >also die daten lesen ein 13d ausgeben und nichts weiter machen? dann >kann es aber sein, Wo hast Du das gefunden? beim 'l' Kommando?
@klaus: also die datenblätter habe ich jetzt, trotzdem danke, ich hab nicht avrprog aufgebohrt (was etwas fatal für meine festplatte wäre) nein avrisp aufgebohrt, ich will auch noch andere geräte (nicht nur avrs unterstützen) z.b. pics und spi e2 speicher. mit der liste hab ich schon angefangen. Atmel hat da recht viel am anfang probiert mit den befehlen, bei den 90s typen hat ja fast jeder seine eigenen befehle für die fuses und lock bits (man kann die wahrscheinlich, mit ein paar Einschränkungen, zusammenfassen) ja das ist das 'l' Kommando @all: dann ist da noch was: beim atmega169 wird das polling über den poll-command unterstützt (wie tiny2313) (mitlerweile hab ich einen 6. sinn entwickelt, der mir hilft bugs (auch wenn ich es nicht will) zu finden)
@marcel, dann schreibst Du vermutlich eine Steuersoftware die avr910 kompatibel ist? AvrProg benutzt zum schreiben der Fuses meistens das "." Kommando, ich werd mal wieder bei einigen chips mit tracen. Beim Mega 16 ist mir bisher noch nichts aufgefallen. >>(mitlerweile hab ich einen 6. sinn entwickelt, der mir hilft bugs >>(auch wenn ich es nicht will) zu finden) Glückwunsch, aber ist das nicht anstrengend wenn Du Dich mit Winxxxx beschäftgst ;-) Viel Erfolg, und schreib uns wo wir das Ergebnis finden. Ciao, Klaus
als basis wollte ich den avrosp nehmen, da funzt das ja eigentlich auch schon, und dann ein Front-End dazu bauen. Das wird dann wahrscheinlich Modul (dlls) basierend (wegen erweiterbarkeit)...
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.