Schon wieder: ID Check

[didi5]

ID-Check-Fehler-7

Liebe Leute, vielen Dank dass Ihr den Fehler analysieren konntet.
Ich bin noch nicht so versiert in Interrupts und hatte daher
erst eimal vieles auskommentiert, damit ich das mir bekannte
austesten konnte: blinkende LEDs, COM usw.
Aber ich hatte das schon am Anfang meiner Tests gemacht, so dass
die verschobenen Vektoren schon in den Flash-Versuchen 1 bis 20
da gewesen sein müssen, ohne dass der ID-Fehler auftrat.
Diese *.mot-Files sind aber überschrieben worden, sie sind also weg.

Es erklärt, warum meine 3 Boards mit Test7_DCF77.mot gesperrt wurden,
nicht aber warum Kollegen den ID-Fehler mit z.B. ldc.mot bekommen.

Ausserdem ist noch zu untersuchen, wie das Entsperren funktioniert.
Nach einigem Probieren ( Protokoll siehe unten ) funktioniert
auch mein Board 2 wieder, obwohl es zwischendurch ca. 1 Std. mit
lcd.mot gesperrt war.

Protokoll vom 7.3.2006

1. M16C-Flasher gestartet und
Board 1 gesteckt ( war 1 Tag auf MOS-Schaumstoff)
connecting .... ok
reading ... auf ID error
00 FF FF FF FF FF FF eingegeben
... failed!
Writing HEX-File (t1.mot) ... .ABORT.OK.

2. M16C-Flasher Board 2 gesteckt ( mit Strom aus/ein )
Connecting ... ok
Reading ... ok ohne ID-Check
Writing HEX-File (t1.mot)... Ok.

3. Wiederholung
Connecting ... ok
...
Writing HEX-File (t2.mot)... Ok.

4. Programming lcd.mot ... OK
das Board 2 lebt wieder Hurra, aber warum ?

5. Board 1 gesteckt
es will immer noch nicht

6. Board 2 gesteckt
lcd.mot funktioniert noch
Wiederholung von
Programming lcd.mot => wieder ID Check failed
Reading => wieder ID Check failed
auch mal mit FF FF FF FF FF FF 00 probiert
das Board 2 ist wieder gesperrt

7. ca. 1 Stunde gewartet

8. Board 2 und 2*16 LCD installiert
mit FTD lcd.mot geflasht
div. Tests ok
Grafik-LCD installiert
LCD64128.mot ok
LCD64128scope.mot ok

=> Board 2 lebt wieder

Mit freundlichen Grüssen

Didi

[js222]

Dann schieb doch mal das ominöse LCD-mot (am besten das ganze Projekt) rüber.

Aber wie schon öfter geschrieben: ID-Fehler ist nicht gleich ID-Fehler, die Ursache kann wieder etwas ganz anderes sein.

[didi5]

Das anhängende Projekt von Burkhard Kainka ist von mir
durch eine blinkende LED1 und einige Kommentare ergänzt
worden.

Grüsse Didi

[didi5]

Ein neuer Anlauf mit Anhang ( das erste ZIP war zu gross)

Didi

[js222]

Bis auf eine verwaiste Endlosschleife kann ich nichts ungewöhnliches entdecken.
Ist wahrscheinlich eher Zufall das es bei "Kollegen" ein ID-Problem gab. Ich zähle übrigens in diesem Thread exakt 2 Kollegen, incl. Dir, oder hab ich da was übersehen?

[stef16]

Mich darfst du nicht dazu zählen. Bei mir läuft noch alles, toi toi toi.

Ich habe nur nach heftigen Installationsproblemen mit der Entwicklungssoftware, fehlenden Datenblättern vom Applikationsboard und vom LCD und dem Lesen der ID-Problemmeldungen Muffensausen bekommen, was ich da als Anfänger so treibe und bin quasi im "Hold-Modus" bis die Sache weiter aufgeklärt ist oder sich mehr melden, bei denen es klappt.

Als nächstes Projekt habe ich eine Art Logikanalysator vor. Ein anderer µC (ATMega128) auf einem anderen Board zickt im Moment und werde versuchen das R8C Board zur Überwachung einiger Portleitungen zu verwenden.

Gruß
Stefan

[didi5]

Da nun das Sperren eines R8C/13 durch ein fehlerhaftes
*.mot-File geklärt wurde, ist nun das Entsperren dran.

Gestern abend habe ich noch einmal mein mit dem fehlerhaften
Test7_DCF77.mot gesperrtes Board 1 getestet, das 2 Tage auf
MOS-Schaumstoff war. Gleich beim ersten Versuch mit dem M16C-Flasher
konnte ich es auslesen und mit z.B. lcd.mot neu flashen.
Auch mit FTD kann ich die Oszilloskope von Burkhard flashen,
alles funktioniert.

Nun meine Frage:
Durch den doppelten Vektor im fehlerhaften sect30.inc
verschieben sich im *.mot die Bytes, die dann mehr
oder weniger zufällig dort landen, wo eigentlich die ID sein
sollte. Der Flasher schiebt das ganze dann in den Controller
und beim nächsten Zugriff gibt es den ID check error.

Nach einer mehr oder weniger langen Wartezeit auf MOS-Schaumstoff
scheint sich diese ID aber zu verflüchtigen, so dass der
R8C/13 wieder benutzbar ist. Das Programm selbst aber ist noch
lauffähig, das Flash soll seine Daten ja auch mindestens einige
Jahre halten können.

Wie kann man das erklären ?

Mit freundlichen Grüssen

Didi

[js222]

Mahlzeit,

gute Frage, nächste Frage bitte

ich hab keine Ahnung wieso sich ein R8C mit einer einmal gesetzten ID mit einer anderen ID öffnen lassen sollte.

Aber es sind natürlich viele Szenarien denkbar bei denen das gar nicht nötig ist:

1. Das eine ID-Byte im mot war ja 00, falls die ID-Bytes in den anderen Stellen auch 00 waren denkt der Flasher vielleicht es handelt sich um einen Fabrikneuen R8C.

2. Der Flasher "passt auf": Er nimmt die Speicherstellen für die ID vielleicht gar nicht aus dem mot sondern nur aus einem ID-File, falls im mot was steht ignoriert er es.

Bei diesen Punkten muss natürlich trotzdem noch etwas zu dem Error geführt haben, im Endeffekt war es vielleicht nur die in der FAQ beschriebene Bootloaderverwirrung (und Dein MOS-Schaum leitet nicht gut, oder manche R8C brauchen Stunden und manche Tage um wieder flashbar zu sein, das ist durchaus möglich).

Vielleicht war es sogar eine Kombination beider Effekte,
der M16C Flasher hat vielleicht jetzt die richtige ID aus einem früheren Versuch genommen (wenn ich mich recht entsinne kann der ja auch IDs loggen) und diesmal war die "Entladezeit" ausreichend, vorher jedesmal nicht.
Also die ID war wirklich verschieden von 00 oder FF.

Es wäre auf jeden Fall ziemlich aufwendig der Sache auf den Grund zu gehen, man müsste ja versuchen alles zu 100% nachzustellen, oder ellenlange Versuchsreihen machen um das Verhalten zu reproduzieren.

Wenn ich das richtig sehe funktionieren jetzt alle Deine R8Cs wieder, falls nicht bitte Bescheid geben.

[didi5]

Vielen Dank für die Antworten.
Ich habe wieder 5 benutzbare R8C/13.

Schönes Wochenende

Didi

[didi5]

Ich habe mal meine Tests mit dem ID Check error zusammengefasst und füge sie als Anhang bei.

Frohes Programmieren

Didi