Schon wieder: ID Check

[didi5]

Vielen Dank für die so schnellen Antworten. Ich werde
heute abend weitermachen, muss aber zwischendurch noch
meine Brötchen verdienen.

Viele Grüsse

Didi

[didi5]

ID-Check-Fehler-4

Heute Versuche mit völlig neu installiertem FTD und M16CFlasher:

Versuch mit FTD
---------------

...
Attempting 9600
Changing baud rate to 9600 bps

Window: ID Check
ID: FF FF FF FF FF FF FF
OK
Error No 16194: ID code check failure

Versuch mit M16C
-----------------

Button Connect:
Connecting at 9600...Ok.
Switching to 9600...Ok.
Reading version information... VER.2.10...Check Ok.

Button Prog:
Reading Test7_DCF77.mot...
Reading Test7_DCF77.mot...Ok. (0x00E000 - 0x00FFFF)
Window: ERROR
ID verification mismatch!
Turn off/on power supply, connect and try again.
OK

Window Select ID
UserID
FF FF FF FF FF FF FF
Okay
Erasing ID check failed!

Als Anhang das Projekt Test7_DCF77.zip, das ca. 20 mal geflasht
wurde und z.Z schreibgeschützt auf beiden R8C/13 lauft:
An Port 4.5 wird das DCF77-Signal gelesen, LED1 blinkt im Takt von
P4.5, an COM werden laufend 0=" " oder 1 ausgegeben, je nach Signal.

Projekt Elektor7_DCF77.zip ist das das Original vom Download,
allerdings von mir neu compiliert und gelinkt, ohne Änderungen.
Es lief auch am 23.02.06 einwandfrei.
Bei dem Versuch, dieses dcf77.mot zu flashen, trat der ID Code check
failure zum ersten mal auf.

MfG Didi

[js222]

Nur ein Schuss aus der Hüfte:

Probier mal die ID: 00 FF FF FF FF FF FF.

Noch ein Hinweis:
Beim M16C-Flasher muss auch der R8C als Proz ausgewählt werden.

[gfx2]

Es ist schon ÜBEL ! Auf der embedded world in Nürnberg habe ich ein kostenloses Exemplar (R5F21114= R8C11) erhalten. Die Bastelkiste auf und schnell die Elektorschaltung nachgesteckt. Software war allerdings nur mit kleinen Problemen zu installieren. Z.B. Fehler schon beim ersten Schritt KD30 Installer meckert bei WinXP zum 16bit Subsystem : Lösung -> command.com ins windows\system32 kopieren (gegoogelt). Dann lustiges Verhalten vom FDT 3.05: bei der Auswahl des D-Protokolls will er keinen COM Port zeigen sondern hat nur den E8 (Debugger)in der Liste. Duch Zufall stellte ich fest, dass man zuerst auf das Protokoll FoUSB geht und dann findet er den COM Port, jetzt wieder zurück zum ersten D Protokoll und schon lässt sich die Abfolge wieder normal durchführen wie bei Elektor beschrieben. Hierzu muss man aber sagen, dass jeder Rechner so seine Einstellungen benötigt.

Der erste Flash war ok und eine kleine Melodie erklang. Das war schön! Dann nächster Schritt mit port_toggle. Hat auch super funktioniert. Als ich dann am nächsten Tag das lcd.mot flashen wollte weil ich ein display angeschlossen habe ging das Elend los. ID CHECK Problem. Alles habe ich ausprobiert in sämtlichen Varianten! Da ich recht viel Erfahrung habe kann ich klar sagen, dass es nicht an meinem Aufbau liegt. Mein Verdacht ist, dass offenbar port_toggle.mot beim flashen etwas anstellt. Eins muss mann lassen: die leds blinken wie verrückt und ich habe ein wenig spass gehabt. Aber war es das schon?
Da im Forum offenbar zu diesem Problem immer noch keine Lösung vorliegt, muss man Glyn/Renesas fragen ob es demnächst eine Lösung geben wird. Wenn der Chip und/oder die Software so unzuverlässig sind dann kann aus dem Blinklicht kein Dinosaurier mehr werden.
Ich werde es noch nochmal recherchieren und hoffe auf einen Lösungsansatz.
Jungs, lasst uns nicht sitzen!

Grüsse

(WinXP sp2, 3,2Mhz PIVht., USB-2-rs232-Adapter(prolific) auf com2)

[didi5]

ID-Check-Fehler-5

3.3.2006
Heute Versuche mit 3 ganz neuen R8C/13 Board 3, 4 und 5.
Board 1 und 2 sind die alten gesperrten.

1. alle 3 mit lcd.mot ( Original von Burkhard Kainka,
von mir mit blinkender LED 1 ergänzt,
neuer Build all mit HEW ) mit FTD geladen
=> funktioniert, also alle 3 Boards OK

2. Board 3 mit dcf77.mot mit FTD geladen
( Original Download aus Projekt Elektor7_DCF77 )
=> funktioniert, also Board 3 OK

3. Board 3 mit test7_dcf77.mot mit FTD geladen
( meine Testvariante aus Projekt Test7_DCF77 )
=> funktioniert, also Board 3 OK

4. Board 3 mit dcf77.mot mit FTD geladen
( Original Download aus Projekt Elektor7_DCF77 )
=> Window ID check
sofort Strom aus, FTD beendet, ca. 15 min. gewartet

5. Strom eingeschaltet
=> test7_dcf77.mot aus 3. noch Ok

6. Board 3 Flashversuch lcd.mot mit FTD ( siehe 1. )
=> Meldung
Attempting 9600
Changing baud rate to 9600 bps
Window ID Check ( wir kennen es schon ... )
Strom ausgeschaltet, Board 3 auf Moosgummi gesteckt

5.3.2006
7. 2 Tage gewartet und eingeschaltet:
=> test7_dcf77.mot aus 3. noch Ok

8. Board 3 mit test7_dcf77.mot mit FTD geladen
( meine Testvariante aus Projekt Test7_DCF77 )
=> Meldung
Attempting 9600
Changing baud rate to 9600 bps
Window ID Check ( wir kennen es schon ... )
Error No 16194: ID code check failure

9. M16C Flasher aufgerufen,
Connect ok
test2.mot auslesen:reading (0x00E0000 - 0x00FFFF)...OK
test3.mot auslesen:reading (0x00E0000 - 0x00FFFF)...OK
test3.mot flashen rogramming (0x00E0000 - 0x00FFFF)...
CRC (0x3781) Ok, Programming Ok.

10. M16C flashen von lcd.mot ( siehe 1.)
reading lcd.mot...Ok. (0x00E000 - 0x00FFFF)
Erasing ALL blocks...OK.
File: lcd.mot (18.02.2006 22:07:48)
Programming (0x00E000 - 0x00FFFF)...CRC (0x05C6) Ok,
Programming Ok.

11. FTD flashen von lcd.mot
=> es funktioniert wieder
auch die anderen Tests lassen sich flashen.

12. leider konnte ich Board 1 und 2 nicht mit dem
M16C Flasher wiederbeleben.

Fazit:
- Der PC wurde neu aufgesetzt ( True Image )
- die R8C-Sofware wurde neu von CD installiert
( HEW, FTD und M16C-Flasher )
- die Buffer von COM1 ( seriell ) und COM5 ( USB )
wurden überprüft
- das originale Elektor-Applicationboard wurde mit
5 verschiedenen R8C/13 bestückt und getestet
- es funktionieren auf einigen Boards die Beispiele
von der CD, vom Elektor-Download und einige eigene
- die ID code check Fehler tauchen auf, nachdem ich
das Test7_DCF77.mot geladen habe, das zwar so läuft
wie programmiert, aber danach ist der R8C/13 geschützt
und ein neues flashen wird verhindert.
- das Board 3 konnte nach 2 Tagen Stromlosigkeit mit dem
M16C-Flasher reanimiert werden, Board 1 und 2 aber nicht
- der Fehler muss über Test7_DCF77.mot und FTD in den
R8C/13 gelangt sein
- mal ist der Fehler wieder weg (Board 3), mal nicht (1 und 2)
- Test7_DCF77.mot wurde in verschiedenen Entwicklungsstadien
ca. 20 mal erfolgreich geflasht
- ein bewusster Schreibschutz ist weder im Projekt noch im
Code eingestellt, trotzdem gibt es einen Schreibschutz
- mit einem bewussten Schreibschutz müsste der der M16CFlasher
eine neuere Version vom gleichen File flashen können,
besonders mit der Einstellung "Extract ID from file"
- das File Test7_DCF77.mot wurde im Explorer zeitweise in
Test7_DCF77-t1.mot umbenannt, später aber wieder zurückbenannt.
Das Filedatum wurde dabei nicht verändert, dennoch meldete
Windows soeben, dass einige Fileattribute nicht kopiert
werden konnten, aber Fileattribute und -namen sollten das
Flashen nicht beeinflussen, besonders keinen Schreibschutz
setzen
- soeben lese ich im Forum, dass das gleiche mit einen R8C/11
und den Files port_toggle.mot und lcd.mot passiert ist, die
bei mir immer funktionierten.

Zusammenfassung:
- es gibt eindeutig Probleme im Zusammenspiel Chip, FTD und HEW,
die nicht vom PC mit Software, vom Kabel ( USB oder seriell ) und
Applicationboard/eigene HW abhängen.

- es wäre nett, wenn sich G.Ewald der Fa. Glyn als Autor der Artikel
sich um das Problem kümmern könnte. Er hat auch sicher Kontakt zu
den Software-Entwicklern der Fa. Renesas, die die Flasher FTD und
M16C geschrieben haben, und die Firmware und das ganze Sicherheits-
konzept entworfen haben.

Ich habe jetzt 5 R8C/13 im Test, von denen ich 2 nicht mehr
benutzen kann. Als Hobbyist ist es zwar schade ums Geld, als
Profientwickler könnte ich aber mit dem Risiko nicht gut leben.

PS: das Test7_DCF77.mot im Archiv Test7_DCF77.zip könnte den Bug
enthalten.


Mit freundlichen Grüssen

Didi

[js222]

Hallo lamken,

>PS: das Test7_DCF77.mot im Archiv Test7_DCF77.zip könnte
>den Bug enthalten.

Ja, offensichtlich enthält es einen Fehler, deswegen habe ich Dir ja eine ID genannt mit der es gehen könnte.

Hast Du das denn mal ausprobiert?


Test7_DCF77.mot setzt eine Stelle der ID auf 00 (vermutlich die Erste, vielleicht aber auch die Letzte, ausprobieren).
Das ist ein Problem denn laut Alexander Pokorny von Glyn enthält die CPU im Auslieferungszustand als ID nur Nullen,
nach dem ersten flashen ist alles auf FF. Wenn jetzt ein mot-File in eine Stelle der ID "00" schreibt, kann weder alles auf 00 noch alles auf FF funktionieren.

Die grosse Frage ist aber:
Wie kommt das ins mot-File?

Da gibt es mindestens 3 Möglichkeiten:
1. Ein echter Bug, unter bestimmten Umständen wird irgendwo in der Toolchain eine Speicherstelle falsch gesetzt.
2. Irgendwo in den Projekteinstellungen ist etwas herumgestellt worden und es ist einem nicht mehr bewusst.
3. Irgendjemand hat im Mot-File herumgewurstelt und sich dabei schön vertan.


Noch ein paar denkbare Möglichkeiten sich eine unbekannte ID reinzubraten (und damit den µC in die Tonne zu kloppen):

-Drüberflashen ohne vorher zu Löschen, insbesondere wenn man mit verschiedenen IDs hantiert.
-Falschen Prozessor gewählt.
-Beim ersten Flashen Stromausfall oder sonstige Kontaktschwierigkeiten.

[js222]

Hallo gfx2,

>Da im Forum offenbar zu diesem Problem immer noch keine
>Lösung vorliegt, muss man Glyn/Renesas fragen ob es
>demnächst eine Lösung geben wird.
>Wenn der Chip und/oder die Software so unzuverlässig sind
>dann kann aus dem Blinklicht kein Dinosaurier mehr werden.

Also erstmal ist der Chip nicht unzuverlässig und der Compiler auch nicht. Über die HEW und FDT kann ich das mangels ausreichender Erfahrung noch nicht behaupten.

Ich nutze verschiedene µC aus der M16-Reihe seit Jahren und hatte exakt einmal ein ID-Problem, dessen Ursache aber eher mit Kommunikationsproblemen zu tun hatte als mit µC oder Software.

Und zweitens:
Es gibt nicht "eine Lösung" weil es verschiedenste Probleme sein können die in einem ID-Error enden.
Welche das sein können ist in den ersten Threads zu dem Thema nachzulesen. Und nicht nur die sollte man sich reinziehen, am besten alle aus der Anfangszeit die sich mit irgendwelchen Errors, "Funktioniert nicht" usw. beschäftigen.
Da werden die meisten Fehler die man machen kann behandelt, angefangen von der richtigen Installation (und deren Fallstricken), der Bedienung der Software und der Hardware, die Probleme mit Betriebsystem (und Einstellungen), RS232-Treibern und -Adaptern.

Eine neue Variante (Bullshit im *.mot-File) haben wir ja gerade hier entdeckt, da kann zumindest der Prozessor und die Flash-Software nichts für.

Es ist halt eine lange Kette vom (funktionierenden) Sourcecode bis zum laufenden Controller, da kann viel schief gehen.

[stef16]

Der grösste Embedded-Betatest aller Zeiten

Wie wäre es mit einem ID-aus-MOT-Auslese-Werkzeug für die MOT-Datei?

Wenn die Toolchain schon in Verdacht gerät, Mist zu bauen, könnte man mit einem ID-aus-MOT-Auslese-Werkzeug wenigstens vor dem Flashen prüfen, ob die ID gemeuchelt wird oder nicht. Bzw. Post-Mortem Quincy spielen

Die Position der ID in der MOT-Datei scheint ja bekannt zu sein.

@ Didi

Hattest du bei den Tests mit dem Board 3 irgendwann mit dem Debugger gearbeitet? Bzw. bei den gesperrten Boards 1+2 auch?

Gruß
Stefan

[didi5]

ID-Check-Fehler-6

Hallo JS222
Ich habe ziemlich viele Kombinationen der ID von 00 00 ... bis FF FF...
ausprobiert, aber nicht in meinen Beiträgen dokumentiert.
Ich bin bei dir, wenn Du meinst, der Bug ist schon im *.mot.
Die grosse Frage: wie kann das passieren?
Wie schon geschrieben, ich hatte mehrfach geflasht, bis der Fehler
auftauchte: HEW öffnen, neues Projekt, in die leere Quelle ein paar
Zeilen tippen oder aus anderen Quellen kopieren, Build all.
Dann FTD öffnen, flashen und testen. HEW und FTD bleiben offen.
Dann die nächste Runde: ein paar Zeilen ...
Das ging ca. 20 mal gut. Aber die alten *.mot-Files werden immer
überschrieben, so dass man sie nicht mehr analysieren kann.
Ich habe immer nur das letzte. Das Projekt wurde nicht geschlossen,
so dass "eigentlich" die Projekteinstellungen nicht verändert worden
sein können.
Am *.mot-File habe ich herumgewurstelt, indem ich es zeitweise
umbenannt hatte, ich wollte es als Zwischenstand sichern.
Aber ich war nicht mit einem HEX-Editor zugange. Ihr könnt im
Test7_DCF77.zip selbst nachsehen, ob sich das Datum dabei verändert
hat.
Erst als der ID check error auftauchte, habe ich HEW und FTD geschlossen.
Falscher Prozessor, Stromausfall und Kontaktschwierigkeiten schliesse
ich aus. Der PC wurde auch völlig neu aufgesetzt ( siehe Beitrag 5 )

Ansonsten läuft es ja gut, gestern habe ich das Grafik-LCD in Betrieb
genommen und die Programme von Burkhard liefen auf Anhieb, heute
kommen meine Varianten dazu.

Hallo Stefan,
zum Debugger bin ich nocht nicht gekommen, ich arbeite also nur
mit der Release-Version. Das liegt nur daran, dass ich noch keine
Zeit dazu gefunden habe.
Ich glaube dass der M16C-Flasher aus dem *.mot-File die ID auslesen
kann mit der Einstellung "Extract ID from file", aber das hat auch
das Problem nicht gelöst und wurde bei Board 1 - 3 probiert.


Mit freundlichen Grüssen

Didi

[js222]

Hallo,

Probier doch bitte bei den "defekten" R8C nochmal die beiden Kombinationen 00 FF FF FF FF FF FF und
FF FF FF FF FF FF 00, wenn Du die Teile noch nicht ausgelötet hast.

Was über die ID bekannt ist sind die Positionen im Speicher, die einzelnen Bytes liegen etwas verteilt.
Im HW-Manual steht beschrieben wo genau.

Beim löschen (was ja vor dem Flashen zwingend erfolgen muss) wird das Flash in den Grundzustand versetzt, der ist FF für jedes Byte.
Im Mot-file steht kein Image des gesamten Flash sondern nur die Bytes die tatsächlich genutzt werden.

In dem fraglichen Mot-File ist genau ein Byte das zur ID gehört (nach meiner Adressbestimmung der S-Records) auf 00 gesetzt und zwar das Byte ID1. Da die anderen ID-Adressen (nach meiner Zählung) überhaupt nicht auftauchen sollte ihr Inhalt FF sein (vom letzten Löschvorgang).

Je nachdem wie das Eingabefenster die Bytes zuordnet gibt es jetzt noch 7 mögliche Kombinationen. Ich gehe aber davon aus das die Bytes dort nicht mehr verwürfelt werden. Deshalb bitte die erste Kombination, vielleicht noch die zweite Ausprobieren.
Wenn Du mehrere ausprobierst bitte daran denken das nach einem Fehlversuch nicht sofort ein zweiter erfolgt.
Mindestens ein paar Minuten den µC Spannungslos machen, besser einen Tag auf MOS-Schaum.

Falls plötzlich ID-OK kommt, sofort den Flash löschen.

Was der M16C-Flasher mit "Extract ID from file" meint weiss ich auch nicht. Als Tool zum verifizieren meiner Adresszählerei hab ich eine Demoversion von "010 Editor" genommen. Doku zum S-Record- (oder Motorola-) Format findet man im Netz und in dem Literaturtip den ich mal gegeben hab: ISBN 3-7785-2824-6.

Was einen (vermeintlichen) Bug in der Toolchain angeht:
Das ist nur eine Möglichkeit von vielen, ich halte es für viel wahrscheinlicher das das Problem woanders liegt.
Ist aber fraglich ob man das jemals herausfinden wird wenn es nicht öfters auftaucht.

Was noch helfen könnte der Sache auf den Grund zu gehen:
Ein Backup des kompletten Projektordners mit dem seltsamen *.mot machen, das Teil danach nochmal kompilieren und schauen ob die Zeile
S20800FFDCF8F800002C
als vorvorletzte Zeile noch vorkommt (egal ob sie gleichen Inhalt hat, wichtig ist der Anfang:S20800FFDC...).
Bitte den komprimierten Ordner dann hier reinstellen.