Hallo, Ich habe hier ein recht seltsames Problem mit einem Attiny25. Vor einiger Zeit habe ich ein Programm in Assembler erstellt (Damals Atmel Studio 6.0) und bin inzwischen auf Studio 7 umgestiegen. Das Programm funktioniert noch immer auf 2 verschiedenen Attiny25. Jetzt versuche ich einen weiteren tiny zu programmieren, gleiches Modell, gleiches Programm, jedoch scheint der Kontroller nicht zu laufen?? Programmieren tu ich mit dem AVRISP MkII, Fehler bekomm ich keine angezeigt. Versucht hab ich das auch schon in AVR Studio 4 und AS6.0. Die Fuses sind korrekt gesetzt (Nur 8MHz RC Oszi und CKDIV8), keine Lock bits. Die Platine auf die der uC eingesetzt wird ist auch in Ordnung, da ich mit einem funktionierenden tiny25 probiert hab. Wenn ich den funktionierenden uC auslese und diese .hex-Datei auf einen neuen schreibe, geht es ebenfalls nicht. uC wurde ebenfalls gewechselt, habe mit 3-4 anderen tinys versucht aber die gehen alle nicht. Nur ein einziges Mal hat es komischerweise geklappt, das Programm lief aber nach aus- und wieder anschalten ging es schon wieder nicht mehr. So und jetzt kommt das Lustige, mein Bruder hat das gleiche Problem. Wir nehmen beide den gleichen Programmer, doch er hat ein anderes Programm (hat ebenfalls vorher gefunzt) und ne andere Platine. Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten diese i.d.R. nicht identisch oder fast identisch sein? Mir scheint als gäbe es ein Problem mit dem ISP oder der Kontroller verträgt was nicht. Was könnte das sein? MfG, Max
Der guade avrdude hat für sowas eine verify-Funktion.
Max schrieb: > Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich > wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten > diese i.d.R. nicht identisch oder fast identisch sein? Definiere "wesentlich". Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen - beispielsweise am Ende wo das Original einfach aufhört. Intel Hex als textbasiertes Format könnte auch anders formatiert sein, IIRC ist z.B. die Zeilenlänge nicht fest vorgegeben.
Jim M. schrieb: > Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen - > beispielsweise am Ende wo das Original einfach aufhört. Nein. Wenn es Unterschiede zwischen dem gerade gebrannten und wieder ausgelesenem Inhalt gibt, ist das natürlich ein Fehler. Dafür gibt es ja die "Verify"-Funktion. Abel.
Max schrieb: > Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich > wesentlich von der unterscheidet, die ich draufgeschrieben habe. Die Daten und die Adressen müssen gleich sein. Hast du die Dateien von der Bedeutung oder von den ASCII-Zeichen her verglichen?
Nur sicherheitshalber: Liegt zwischen VCC und GND möglichst nahe am IC ein keramischer Kondensator 100 nF? Und ich hoffe, am Reset-Pin liegt kein Kondensator von wesentlicher Größe.
Jim M. schrieb: > Max schrieb: >> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich >> wesentlich von der unterscheidet, die ich draufgeschrieben habe. Sollten >> diese i.d.R. nicht identisch oder fast identisch sein? > > Definiere "wesentlich". > Ein ausgelesenes Hex File wird praktisch immer Unterschiede aufweisen - > beispielsweise am Ende wo das Original einfach aufhört. > > Intel Hex als textbasiertes Format könnte auch anders formatiert sein, > IIRC ist z.B. die Zeilenlänge nicht fest vorgegeben. Ich meine damit, dass von Anfang bis Ende Unterschiede auftreten. Es lassen sich nur manchmal mehrere aufeinanderfolgende Bytes finden die gleich sind. Auch die Adressen am linken Rand sind nicht 1:1 gleich. Sobald es geht werde ich den uC nochmal auslesen und die Resultate hier posten damit ihr seht was ich meine. Wolfgang schrieb: > Max schrieb: >> Beim Auslesen des uC ist mir aufgefallen, dass die .hex-Datei sich >> wesentlich von der unterscheidet, die ich draufgeschrieben habe. > > Die Daten und die Adressen müssen gleich sein. Hast du die Dateien von > der Bedeutung oder von den ASCII-Zeichen her verglichen? Ich habe die Dateien mit Notepad geöffnet und so Zeile für Zeile verglichen. Das Komische ist, dass im AS die verify-Funktion nach dem flashen keine Fehler anzeigt. Es muss etwas geschehen nachdem ich das Board vom Strom trenne, die Frage ist nur was. Ab dem Punkt bin ich am Ende mit meinem Latein.
Edi R. schrieb: > Nur sicherheitshalber: Liegt zwischen VCC und GND möglichst nahe > am IC > ein keramischer Kondensator 100 nF? Und ich hoffe, am Reset-Pin liegt > kein Kondensator von wesentlicher Größe. 100nF-Kondensator ist drauf und Reset-Pin ist nicht angeschlossen. An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne Probleme.
Max schrieb: > An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne > Probleme. Ohne richtiger Beschaltung kann es mal funktionieren, und mal nicht. Deshalb meine Frage.
Max schrieb: > An der Platine liegts ja eh nicht weil andere uC drauf laufen ohne > Probleme. Dann gibt es nur noch eine Möglichkeit. Das sind Fakes aus China und es gibt keine Möglichkeit das Problem zu beheben, weil heute alles aus China kommt :-(
> Das Komische ist, dass im AS die verify-Funktion nach dem flashen > keine Fehler anzeigt. Dann ist da auch kein Fehler. Du kannst nicht einfach zwei hex Dateien miteinander vergleichen, die auf unterschiedliche Weise erstellt wurden. Beschäftige Dich mal mit dem Dateiformat, dann wirst du sehen, warum das so ist. Zeige und den Schaltplan, detaillierte Fotos von Aufbau und das Programm. Es ist recht warscheinlich, dass Hardware oder Software einen Fehler enthalten. > Das sind Fakes aus China Ich hatte mit Fake Produkten aus China noch nie solche Grundsätzlichen Probleme. Funktioniert haben sie immer. Wenn aber irgend etwas außerhalb der Spezifikation betrieben wird, dann kann es durchaus sein, dass ein Fake oder gar ein Original aus einer anderen Serie empfindlich reagiert.
Mal ne blöde Idee, hast du das richtige herfiel gewählt? Das AVR Studio öffnet den zuletzt geöffneten Ordner, nicht den, der aktuell in Bearbeitung ist. Zumindest ist das bei der alten Version der Fall (4.19 oder so).
npn schrieb: > Was meinen? Nur zwei Fehler innerhalb eines Wortes mit sieben Buchstaben - stell dich nicht so an ;-)
Am Tablet getippt, die Tastatur und ich wir haben Kompatibilitätsprobleme. Soll natürlich Hexfile sein.
Max schrieb: > und Reset-Pin ist nicht angeschlossen. Dann sollte das Programmieren gar nicht funktionieren, das kann SO also nicht sein - wie so oft: Schaltplan zeigen! fxjkcyxmk
fxjkcyxmk schrieb: > Max schrieb: >> und Reset-Pin ist nicht angeschlossen. > > Dann sollte das Programmieren gar nicht funktionieren, das kann SO also > nicht sein - wie so oft: Schaltplan zeigen! > > fxjkcyxmk Ich war wohl nicht klar genug, auf dem Programmierboard ist der natürlich dran, nur auf dem Anwendungsboard nicht. Nen Schaltplan von dem Programmierboard hab ich nicht aber das hatte nie Probleme, wir haben damit Dutzende Controller geflasht. Fred F. schrieb: > Mal ne blöde Idee, hast du das richtige herfiel gewählt? Das AVR > Studio > öffnet den zuletzt geöffneten Ordner, nicht den, der aktuell in > Bearbeitung ist. > Zumindest ist das bei der alten Version der Fall (4.19 oder so). Das überprüfe ich jedesmal und ist das richtige file (in meinem Fall im Projektverzeichnis -> Debug) Stefan U. schrieb: > Dann ist da auch kein Fehler. Du kannst nicht einfach zwei hex Dateien > miteinander vergleichen, die auf unterschiedliche Weise erstellt wurden. > Beschäftige Dich mal mit dem Dateiformat, dann wirst du sehen, warum das > so ist. Hier sind Beispielzeilen (Anfang der Datei) von einem einfachen Programm: vom Studio erstelltes hex-file: :020000020000FC :020000000EC030 :02000800D3C063 :10001E000FED0DBF00E00ABD03BF0FE000BF00E013 :10002E000CBD04E009BFBA9AB998B89A789450E01A :10003E0060E0B19BFDCFF894639523E100000000D2 :10004E002A95E1F70000B199F7CF789453955B307C ausgelesenes hex-file: :100000000EC0FFFFFFFFFFFFD3C0FFFFFFFFFFFF9B :10001000FFFFFFFFFFFFFFFFFFFFFFFFFFFF0FEDF2 :100020000DBF00E00ABD03BF0FE000BF00E00CBD44 :1000300004E009BFBA9AB998B89A789450E060E0A1 :10004000B19BFDCFF894639523E1000000002A9551 :10005000E1F70000B199F7CF789453955B3079F7C9 Der Anfang mit der :02-Datenlänge ist ja sicher normal, aber dass der Rest so unterschiedlich ist versteh ich nicht. Es gibt da ja nur 1 Format und zwar das von Intel. Diese Unterschiede sind vielleicht auch normal, hab nie so drauf geachtet und kenn mich da nicht wirklich aus aber deswegen frag ich ja ob das ein Problem sein könnte.
Mach das mal mit einem Format wo manvernünftig vergleichen kann, also z.B. .bin und dann hexdump vergleichen. Denkbar wäre dass durch fehlenden Brwon-Out der Controller mist macht und irgendwelche Code-Sequenzen durchnudelt die den Flash shreddern.
nicht jeder Texteditor ist geeignet hex-Files zu öffnen. Beispielsweise wird das CR-LF wie es zu DOS Zeiten üblich war in ein LF umgewandelt oder TAB wird in eine Folge Blancs gewandelt, ärgerlicherweise speichern manche Editoren die Änderungen ungefragt. Besser Hex Editor verwenden.
Max schrieb: > dass der > Rest so unterschiedlich ist versteh ich nicht Dann lies bitte die Definition für Intel-Hex Code. Der Studio Code enthält die Bytes in der Reihenfolge und an den Adressen, wie der Compiler sie ausgespuckt hat. Das muss nicht linear sein und nicht bei 0 anfangen. Die Ladeadressen müssen nicht stetig ansteigen. Löcher sind auch zulässig. Der ausgelesene Code fängt immer bei 0 an und ist "in einem Stück". Ein Vergleich im Editor ist aufwändig und fehlerträchtig. Aber, wie schon von Johann geschrieben, gibt es dafür Werkzeuge.
Vielen Dank für die Antworten. Ich habe jetzt wie Johann beschrieben hat die hex files in .bin umgewandelt und dann mit einem online hexdump tool verglichen. Sie sind in der Tat 100% identisch und damit meine ich die Datei, die vom Studio generiert wird, die ausgelesene .hex vom uC der funktioniert und von einem der nicht funktioniert. Alle sind gleich. Hardware ist auch i.O. da mein alter tiny (der übrigens von der selben Serie stammt) ja läuft. Ist ja schon fast wie Hexerei..
Zur Info, ich habe einen MD5 Hash Generator benutzt und die Resultate so verglichen.
Beschaltet den reset doch wie im Datenblatt angegeben
Die Fuses schon mal ausgelesen und verglichen?
Und dann sollte man noch die Registeradressen im Datenblatt vergleichen. Nicht alle Register lassen sich per LDI, SBI, JBS und dergleichen ansprechen. Auf einem anderen Controllermuss dasselbe Regsiter per LDS, STS, STD und dergleichen ansprechen. Der ASM zeigt keinen Fehler, es geht einfach nicht. Die Immediate Register muessen unterhalb 32 oder so sein. Oberhalb kann LDI und dergleichen nicht zugreifen.
Was macht der Code denn? Der interne RC-Oszillator ist relativ ungenau, ein kritisches Timing kann da beim einen Chip noch passen, beim anderen nicht.
Der Nuller schrieb: > Und dann sollte man noch die Registeradressen im Datenblatt vergleichen. > Nicht alle Register lassen sich per LDI, SBI, JBS und dergleichen > ansprechen. Auf einem anderen Controllermuss dasselbe Regsiter per LDS, > STS, STD und dergleichen ansprechen. Der ASM zeigt keinen Fehler, es > geht einfach nicht. Sind die Registeradressen tatsächlich bei zwei gleichen ATtiny25 verschieden? Muss man wirklich die Files des einen ATtiny25 mit dem anderen ATtiny25 vergleichen? Der TO schrieb: Max schrieb: > Das Programm > funktioniert noch immer auf 2 verschiedenen Attiny25. > Jetzt versuche ich einen weiteren tiny zu programmieren, gleiches > Modell, gleiches Programm, jedoch scheint der Kontroller nicht zu > laufen??
Mal ganz abgesehen davon, dass beim ATtiny25 die Registeradressen bei 0x3F enden.
Ich würde ein Minimalprogramm schreiben, dass zum Beispiel eine LED toggelt. Dieses in den funktionierenden und den nicht funktionierenden Controller brennen. Falls eines nicht geht => Controller defekt / Fake. Falls beide gehen => Programm benötigt kleinere Toleranzen als der Controller hergibt (zum Beispiel des RC-Oszillators).
Wie Jim schon schrieb, gibt es oft Unterschiede im Hex-File, zwischen rein und raus. Und das nur durch die unterschiedliche Formatierung. Ein zweiter Pferdefuß ist der, dass das Leseprogramm keine Ahnung hat, wie lang das Programm ist. Also wird meist der ganze Speicher ausgelesen. Also stimmt schon mal die Länge nicht. Wurde vor dem Schreiben nicht - unnötigerweise - der gesamte Speicher gelöscht, so findest Du "hinter" Deinem Programm noch Reste, der vorherigen Versuche. So diese zwischenzeitlich mehr Platz benötigten.
:
Bearbeitet durch User
Fred F. schrieb: > Am Tablet getippt, die Tastatur und ich wir haben > Kompatibilitätsprobleme. Ach, und auf deinem Tablet kannst du nicht lesen was du schreibst? Das wäre mir neu, dass Tablets so funktionieren.
Hubert G. schrieb: > Die Fuses schon mal ausgelesen und verglichen? Ja. Hmmm schrieb: > Was macht der Code denn? > > Der interne RC-Oszillator ist relativ ungenau, ein kritisches Timing > kann da beim einen Chip noch passen, beim anderen nicht. Der Code soll ein Soundmodul ansteuern und gibt einen Takt sowie die abzuspielende Adresse an das Modul nachdem man die gewünschte Audiodatei mit ein paar Schalter ausgewählt hat. An den RC Oszillator hatte ich auch schon gedacht weil der Code zufällig schon mal funktioniert hat. Ein paar ms beim Takt können genügen um das Programm aus der Bahn zu werfen, allerdings bei +-10% Abweichung und 1MHz wäre das gerade mal 0,1us/Befehlszyklus und bei ausschließlich 8-bit timer macht das auch noch nicht viel aus. Ich werde trotzdem mal versuchen den Oszi zu kalibrieren um zu sehen ob es nen Unterschied macht für den Fall dass ich mich irre. Sebastian S. schrieb: > Wie Jim schon schrieb, gibt es oft Unterschiede im Hex-File, > zwischen > rein und raus. Und das nur durch die unterschiedliche Formatierung. > > Ein zweiter Pferdefuß ist der, dass das Leseprogramm keine Ahnung hat, > wie lang das Programm ist. Also wird meist der ganze Speicher > ausgelesen. Also stimmt schon mal die Länge nicht. > > Wurde vor dem Schreiben nicht - unnötigerweise - der gesamte Speicher > gelöscht, so findest Du "hinter" Deinem Programm noch Reste, der > vorherigen Versuche. So diese zwischenzeitlich mehr Platz benötigten. Die Unterschiede kann ich ausschließen da ich mit der Methode wie vorhin beschrieben die files verglichen habe und nix gefunden habe was Probleme macht.
> Hardware ist auch i.O. da mein alter tiny (der übrigens von der selben > Serie stammt) ja läuft. Als erste grobe Annahme ist das Ok, aber da du Probleme hast, sollte man etwas weiter denken. Wenn der Controller irgendwo im Grenzbereich (außerhalb der Specs) betrieben wird, können winzige Unterschiede im Chip durchaus ausschlaggebend für geht/geht nicht ausschlaggebend sein. Zum Beispiel könnte es druchaus sein, dass der alte Chip 2,5V als High Pegel interpretiert, während der neue dies als Low auswertet.
Stefan U. schrieb: >> Hardware ist auch i.O. da mein alter tiny (der übrigens von der > selben >> Serie stammt) ja läuft. > > Als erste grobe Annahme ist das Ok, aber da du Probleme hast, sollte man > etwas weiter denken. > > Wenn der Controller irgendwo im Grenzbereich (außerhalb der Specs) > betrieben wird, können winzige Unterschiede im Chip durchaus > ausschlaggebend für geht/geht nicht ausschlaggebend sein. > > Zum Beispiel könnte es druchaus sein, dass der alte Chip 2,5V als High > Pegel interpretiert, während der neue dies als Low auswertet. Das ist es ja, die Specs wurden alle berücksichtigt. Betrieben wird er mit 3,3V bei Zimmertemperatur und ist vorschriftsgemäß mit 100nF direkt an VCC und GND entstört. Geflasht wird er bei 5,5V (ist eig. ne Batterie mit 4,8V aber vollgeladen hat die 5,5). Das stellt doch kein Problem dar oder? Um sicherzugehen hatte ich schon mal ne Si-Diode zwischen Batterie und uC gehangen, hat aber nichts gebracht.
Vier NiMh Zellen haben frisch geladen sogar fast 6V. Ich habe AVR's in Experimenten schon oft mit 5,8V betrieben, so daß ich davon ausgehe, daß deine 5,5V nicht die Problemursache sind.
> ... gibt einen Takt sowie die abzuspielende Adresse ...
Klingt doch recht überschaubar, könnte man das vielleicht mal sehen?
Hallo, irgendwie fehlt das doch etwas. Ich sehe keinen Schaltplan und keine detail Bilder vom Aufbau. Hier wird das Problem zu finden sein. Der gesamte Prosatext beschreibt nicht die Realität !
Zur Info, der Code läuft wieder. Wie es scheint hat mein AVR ISP sich was eingefangen denn nachdem ich mir einen neuen ISP bestellt und mit dem geflasht hab geht wieder alles, auch der Code von meinem Bruder. Blieb ja nichts anderes mehr übrig aber was für ein Mist ist das dass der ISP nach fast 10 Jahren auf einmal sowas macht?
Max schrieb: > Blieb ja nichts anderes mehr übrig aber was für ein Mist ist das dass > der ISP nach fast 10 Jahren auf einmal sowas macht? So ist das im realen Leben: nichts lebt/hält ewig... Da fällt mir der "tiefsinnige" Spruch ein: Was soll denn da kaputt sein? Gestern gings doch noch! ;-)
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.