Attiny25 gleiches Programm geht auf anderem Kontroller nicht

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.

Die Daten und die Adressen müssen gleich sein. Hast du die Dateien von 
der Bedeutung oder von den ASCII-Zeichen her verglichen?

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.

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.

Fred F. schrieb:
> das richtige herfiel

Was meinen?

npn schrieb:
> Was meinen?

Nur zwei Fehler innerhalb eines Wortes mit sieben Buchstaben - stell 
dich nicht so an ;-)

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.

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

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).

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?