Schon wieder: ID Check

[js222]

Original von moud vom 16.02.2006 18:12:40
Also:

P.S. Diese äuserung finde ich ziemlich unverschämt!
"(Oder der Fehler ist irgendwo zwischen den Ohren . "

Ich kann Dir aus langjähriger Erfahrung sagen:
In den meisten Fällen liegt der Fehler wirklich zwischen den Ohren, wer sich selbst gegenüber ehrlich ist der weiss das auch.
Gerade bei komplexeren Sachen haperts oft an ganz primitiven
Dingen und man sucht naturgemäss bei den Komplizierten.
Da fällt einem erst später auf das man was falsch angeklemmt, verstanden, bedient oder sonstwas hat.

Aber davon mal abgesehen, warum hängt am Ende des Satzes wohl ein Smiley?
Ich kann Deinen Frust ja nachvollziehen, aber nicht das du eine augenzwinkernde Bemerkung gleich persönlich nimmst.


Zurück zum Problem:
Warum schliesst Du einen Verdrahtungsfehler aus?
Nur weil bestückte Platinen im Spiel sind, bedeutet das ja nicht das das Drumherum richtig angeschlossen ist und z.B. Dein Netzteil eine saubere Versorgung liefert, oder das Dein RS232-Kabel in Ordnung ist.
Aber vermutlich hast Du das ja alles schon gecheckt.

[moud]

Joa, hab ich schon!
Sörry das ich so gereitzt reagiert habe... war schlecht drauf !

Mir ist nochwas eingefallen:
Gibt es eine möglichkeit den Chip nicht über Software wieder in den Auslieferungszustand zu versetzen?

MfG moud

[js222]

Hallo,

ich weiss nur von anderen M16Cer Typen das sie mittels einem Parallelprogrammer und evtl. spezieller Software wohl auch zugriff auf die ID bieten. Zumindest habe ich so was mal vor Jahren auf irgendeiner Renesas Seite gelesen.

Ob das auch für den R8C gilt? Keine Ahnung.
Ich kann höchstens mal schauen ob es für meinen älteren Universalprogrammer Softwareupdates gibt und dort der R8C in der Device-List auftaucht.
Das würde aber noch lange nicht heissen das es damit geht,
weil das Teil ja auch einfach nur die seriellen Pins zum proggen verwenden könnte.
Es bleibt auch die Frage ob das ohne speziellen Programmieradapter geht, das kleine Board ist zwar ein prima Adapter aber normalerweise wollen die Universal-Proggerhersteller ihre eigenen (teuren) Adapter verkaufen. Man müsste wohl zumindest den Quarz auslöten.

Aaabeer:
Ich glaube nach wie vor nicht so richtig an ein echtes ID-Problem. Ich hatte das vor ca. 2 Jahren ein eiziges Mal an einem M16C26. Da gab es eine wundersame Heilung über Nacht, aber auch weitere Kommunikationsprobleme.
Nach eingehender Fehlersuche (und genauem Datenblattstudium) war der Fehler gefunden.
Ein bestimmter Pin der Seriellen muss einen Pulldown sehen wenn man das Teil im Downloadmodus betreiben will.

Auf dem Board waren 2 Prozessoren, der eine liess sich immer Programmieren, der andere nach Lust und Laune.
Am ersten hing an diesem Pin ein Optokopplereingang der zufälligerweise den Part des Pulldowns übernahm, am anderen eben gar nichts. Es gibt nichts übleres als schwimmende Eingänge, man braucht nur drüberzupusten und der Zustand ändert sich.

Aber im Grunde lag hier der Fehler auch zwischen meinen Ohren (Datenblatt nicht an den richtigen Stellen gelesen).

Dazu kommt: Ein gemeldeter ID-Check Fehler muss gar keiner sein, beim R8C vom Elektor Board habe ich ihn 1-2mal gesehen, es war aber eher eine Software/Com-Port verwirrung. Ich habe schonmal mehrere Programme die die serielle nutzen laufen, wenn eines davon unsinn macht kommt es zu seltsamen Effekten, manchmal hilft dann nur der Neustart.

So jetzt hab ich erstmal genug geschrieben, bitte schreib Du mal was: Wie genau ist der Fehler aufgetreten, gab es andere Fehlermeldungen im Vorfeld, wieviele Programmierungen hatten bis dahin funktioniert, wie sieht Dein Versuchsaufbau aus, nutzt Du einen USB-Adapter, spukt auf Deinem PC irgendeine Soft oder Treiber herum die an den Seriellen rummachen, gibt es Störquellen (siehe Brummschleifen unter "High Voltage Hinweis").

Du könntest auch mal versuchen die Kommunikation mittels einer zweiten serielellen (Rxd zum Rechner aufsplitten) und eines Comportüberwachungstools abzuhören um zu sehen was vom R8C zurückkommt und ob das Sinn macht.

[didi5]

Ich habe auch das ID Check-Problem mit 2 R8C/13-Boards.
Ich verwende das Original Elektor-Applicationboard und habe
damit die Glyn-Programme von der CD jingle_Bells,
port_toggle und timer_interrupt vielfach als Original
und als von mir veränderte Variante mit dem FTD geflasht.
Alles lief einwandfrei.

Dazu wurden die Programme vom Download lcd, HD44780_4Bit,
elektor_1 und Scope im Original und als meine Variante
mit Erfolg auf beiden Boards geflasht.

Heute nun hatte ich mir das DCF77 vorgenommen.
Das Original lief nicht ganz so wie erwartet, lies sich
aber problemlos flashen. Meine Testversionen liefen heute
ca. 20 mal einwandfrei:
das Signal wurde erkannt, die LEDs blinken usw.

Und dann wollte ich noch einmal das Original testen und der

Error No 16194: ID code check failure

tauchte auf. Und zwar auf beiden Boards.
Auf beiden Boards läuft noch das letzte Programm vor dem
erfolglosen Flashen, also können sie nicht völlig defekt sein.

Das Herumspielen mit der
ID Check 00 00 00 00 00 00 00 und ff ff ff ff ff ff ff
bringt nichts.

Das Stecken auf Moosgummi für ca. 1 Stunde auch nichts.
Weiter wurde ausprobiert:
Strom aus/ein, PC Reboot, FTD neu starten, alte definitiv
lauffähige Programme starten ...
die Spannung an Vss ist 5.04 Volt abgeleitet vom USB.

Die Tipps in diesem Forum habe ich auch gelesen und ich
glaube auch nicht, dass sich ein Verdrahtungsfehler oder
ähnliches eingeschlichen hat.
Dass beide Boards den gleichen Fehler zeigen ist auch seltsam.
Immerhin habe ich sie vielleicht 200 mal geflasht.

Kennt jemand aus dem Forum ein Masterclear oder ähnliches?

Didi

[js222]

In so einem Fall (beide Teile zeigen ab einem Zeitpunkt gleichzeitig den gleichen Fehler) würde ich den gesunden statistischen Menschenverstand walten lassen:
Der Fehler (zumindest die Ursache) liegt mit sehr geringer Wahrscheinlichkeit auf den Boards, er ist eher im Drumherum zu suchen.

Das Übelste bei der Fehlersuche:
Von irgendeinem Sachverhalt (sei es weil man schon 3mal (an falscher Stelle?) nachgesehen hat, oder aus purer Faulheit ("das jetzt zu prüfen wäre jetzt aber Aufwendig, ausserdem kann das ja nicht sein weil...) annehmen das er real so vorhanden ist wie man glaubt (hofft, wünscht, betet...).

Die beste Laborausstattung zur Fehlersuche ist Ausdauer, Geduld und das Wissen um die Wichtigkeit von Pausen.
Schliesslich muss der Akku der Hardware auf der Brain 0.9beta läuft ja auch mal aufgeladen werden.

Der Feind jeder Fehlersuche ist Selbstbeschiss, den darf man erst üben wenn der Fehler gefunden ist:
(Nuhr-Mode On) Jaaa... im Datenblatt stand das aber erst auf Seite 912..., was kann ich dafür wenn sich der Draht da losrödelt..., ...Scheiss Win****..., Trenntrafo? brauch ich ni



Ich weiss, das hilf Dir jetzt nicht wirklich weiter, aber was soll ich machen, ich hab keine Patentlösung für das Problem. Als Ursache kommt vieles in Frage die meisten Artikel dazu kamen kurz nach dem Dezemberheft, evtl. steht auch noch nicht alles in der FAQ. Am Besten durchbeissen (-lesen) vieles wird nicht weiterhelfen, kann aber helfen auch andere Infos zu finden wenn die Teile wieder laufen und das nächste Problem auftritt.

[didi5]

Gestern abend habe ich weiter geforscht und
Folgendes ausgetestet:

den FTD neu installieren, leider werden die Settings
( evtl. auch die Falschen ) in der Registry gespeichert.

die Prog. Schnitstelle zwischen USB ( COM5 ) und normaler
COM1 hin- und hergeschaltet.

Dabei habe ich festgestellt:
der FTD versucht die Kommunikation mit dem R8C/13 beginnend
mit 9600 bis 1200 Baud.
Wenn der R8C/13 gesteckt ist, antwortet er auch mit 9600
Baud.

Nun meine Vermutung:
Ein frischer R8C/13 würde dann sagen, er ist bereit für ...;
(kann ich leider nicht ausprobieren - ich habe leider keinen
frischen mehr).
Meine sagen dann aber, ich bin schreibgeschützt, bitte
gib mir den ID Code. Daraufhin öffnet sich im FTD die
ID Code Box ( siehe FTD-Usermanual Seite ... ) und fragt
den ID Code ab;
default : 00 00 00 00 00 00 00, wenn man auf das *.mot
klickt, wird FF FF FF FF FF FF FF vorgeschlagen.
Bei OK wird das zum R8C/13 gesendet. Dieser ist damit
unzufrieden, denn es ist unwahrscheinlich, dass es passt.
Also gibt er den Fehler 16194 zurück.
Der FTD meldet dann :
Error No 15194: ID Code check failure
und das wars dann.

Nun die spannende Frage : wie kommt der ID Code
( schreibschutz ) in den R8C/13.
Über den Quellcode sicher nicht, ich weiss nicht, wie man
das macht und eingetippt habe ich das auch nicht. In den
diversen Header-, und Projekt-Files vermutlich auch nicht,
ich habe diese ja gar nicht angefasst und mit ihnen
mindestens 20 mal erfolgreich compiliert, assembliert und
gelinkt. Also kann der ID Code eigentlich nicht im *.mot
File sein. Damit ist der HEW erst einmal unverdächtig.

Und nun zum FTD. Er hat definitiv ca. 20 mal einwandfrei
geflasht. Vielleicht hat er ja beim 21. mal gefunden,
nun ist aber gut, ich gebe einen Schreibschutz mit
- begrenzte Testversion ? oder einfacher Programmierfehler ?
oder ungeschickte Parameter ? oder ? oder ?
Jedenfalls war mein erster R8C/13 gesperrt.

Und nun mein Fehler: ich habe den FTD "nicht" geschlossen und
ihn wieder neu aufgerufen. Dafür habe ich den R8C/13 gewechselt
und ihn mit den alten ( falschen ) Einstellungen geflasht
und gesperrt.
Ergebnis: ich habe nun 2 R8C/13 mit dem gleichen Testprogramm,
das zwar läuft, aber noch lange nicht fertig ist.
Dummerweise sind nun beide R8C/13 schreibgeschützt, so dass
ich nicht weitermachen kann, solange ich mir keine frischen
besorgt habe.

Man könnte nun die Autoren, die Fa. Glyn oder die Fa. Renesas
fragen, wie es sich mit dem FTD und dem ID Code verhält.
Ob sich meine Vermutungen bestätigen, oder ob ich völlig
daneben liege. Da hat sich sicher jemand schon Gedanken gemacht
wegen Softwareklau usw.

Wenn ich so im Forum stöbere, bin nicht der erste und der
einzige, der auf dieses Problem gestossen ist und nun
unbenutzbare R8C/13 hat.

Mit feundlichen Grüssen

Didi

[js222]

So weit ich mich erinnere haben die meisten die diese Fehlermeldung hatten (und das waren anfangs nicht wenige) es später doch wieder zum laufen gebracht. Manchmal ging es auf wundersame Weise am nächsten Tag wieder.
Was nichts bringt (wenn es ein echter ID-Fehler ist, es scheint auch welche zu geben die nur mit der Kommunikation zu tun haben): Immer wieder in kurzen Abständen versuchen.
Da ist wohl eine Totzeit eingebaut die schnelles durchprobieren von allen möglichen IDs verhindern soll.

Was bei der Methode "Spannungsfrei machen und warten" beachtet werden muss: Es muss alles ab, auch die RS232-Verbindung, einfach alles wodurch das Teil noch ein paar hundert Millivolt bekommen könnte.
Am besten VCC und GND mittels 1k oder so kurzschliessen und über nacht in eine Metallkiste.
Übrigens kann die ID meines wissens durchaus im *.mot sein, da steht ja im Prinzip nur drin welche Daten an welche Adressen geschrieben werden sollen. Ist zwar fraglich wie der da reingekommen ist aber es würde ja (rein theoretisch) reichen einmal ein falsches File übergeben zu haben.

Es ist auf jeden Fall nicht so das sich die Software plötzlich überlegt eine ID zu vergeben, auch nicht nach tausend Versuchen.

Probier mal den alternativen Flasher aus:
http://www.m16c-flasher.de/
nimm die Beta-version und versuche erstmal nur auszulesen und zwar nur mit den Baudraten die mit 20MHz überhaupt möglich sind.
Als ID immer nur alles 00h oder FFh versuchen.

Auf Seite 164 im Manual steht übrigens wo die IDs im Speicher liegen, mit einer Spezifikation des Mot-Formats könnte man die letzten Mot-Files die Du geflasht hast prüfen ob (und was) an diese Positionen geschrieben worden ist.
Ich würde auch mal die Unterverzeichnisse und sämtliche Projekteinstellungen durchforsten ob da nicht doch irgendwo was eingetragen ist oder eine Datei rumliegt die mit ID irgendwas zu tun haben könnte.
Aber nicht wild drauflosändern, sondern Aufschreiben was man wo geändert hat, besser vorher fragen ob es überhaupt was damit zu tun hat.

Der HEW ist übrigens nicht unverdächtig, dort muss man am Anfang eines Projekts definitiv auswählen ob man einen ID-Schutz vergeben will oder nicht.

Irgendetwas ist auf jeden Fall plötzlich anders gewesen und seitdem funktionierts nicht mehr. Ich würde auch mal scharf darüber nachdenken was das gewesen sein kann und mein gesamtes Vorgehen nochmal mit Schritt für Schritt mit der Anleitung im Heft (und eventuellen Korrekturen auf der R8C-Service-Seite) abgleichen.
Weil eins ist sicher: "Von selbst" denkt sich der µC nicht plötzlich eine ID aus.

[js222]

Original von JS222 vom 18.02.2006 13:50:08
Hallo,

ich weiss nur von anderen M16Cer Typen das sie mittels einem Parallelprogrammer und evtl. spezieller Software wohl auch zugriff auf die ID bieten. Zumindest habe ich so was mal vor Jahren auf irgendeiner Renesas Seite gelesen.

Ob das auch für den R8C gilt? Keine Ahnung.
Ich kann höchstens mal schauen ob es für meinen älteren Universalprogrammer Softwareupdates gibt und dort der R8C in der Device-List auftaucht.

Hab das mal gechecked, R8C wird vom meinem betagten All-11 nicht unterstützt.

[didi5]

ID-Check-Fehler-3.txt

Auch das Stecken auf leitfähigem Moosgummi 2 Tage lang hat
den Fehler nicht beseitigt.

Ich habe dann die Beta-Version des M16C-Flashers heruntergeladen
und installiert. Das Programm kommuniziert einwandfrei mit COM1
des PCs zu beiden Ports COM und Prog des Application-Boards
mit 9600 Baud.
Die Ausgabe des Testprogramms kann im Terminalmode gesehen werden.
Am ProgPort kann man sich verbinden...

Nachfolgend die Anzeige im Hauptfenster des M16C-Flashers:

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


Aktion: Auslesen des R8C/13
---------------------------

Button Read
Window Read Chip
Allowed addressrange:
Mian memory: 0x00C000 - 0x00FFFF
Startaddress 0x00c000
Endaddress 0x00FFFF

Button: Okay
Window: Save file z.B. test1.mot

Window ERROR
ID verification mismatch!
Turn off/on power supply, connect and try again.

Window Select ID
Button Last prog. ID 00 00 00 00 00 00 00
Button Extract ID from file
Button User ID 00 00 00 00 00 00 00
Okay

Console:
reading (0x00C000 - 0x00FFFF)...
reading 0x00C000...
Reading 0x00BFFF... failed! - File will be INVALID!
Writing HEX-file (test1.mot)... .ABORT. Ok.


Aktion: Beschreiben des R8C/13 mit dem letzten geladenen File,
das auf beiden Trägerboards läuft:
---------------------------------------------------------------

Button Prog
Window Prog new file
Auswahl ... Test7_DCF77.mot


Window Select ID
Button Last prog. ID 00 00 00 00 00 00 00
Button Extract ID from file
Button User ID 00 00 00 00 00 00 00
Okay

ergibt auf Konsole
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.
button OK


Window Select ID
Button Last prog. ID 00 00 00 00 00 00 00
Button Extract ID from file
Button User ID 00 00 00 00 00 00 00
Okay

ergibt auf Konsole
(ID: 00 00 00 00 00 00 00)
Erasing ID check failed

Es gibt offenbar in beiden R8C/13 einen ID-Code, der nicht zu
dem ID-Code des Test7_DCF77.mot 00 00 00 00 00 00 00 passt.
Darum gibt es dann den ID check failure.
Damit ist der R8C/13 schreibgeschützt und für weitere Tests unbrauchbar,
es sei denn, es gibt einen Generalschlüssel oder andere Möglichkeiten.

Bleibt noch die Frage, wo denn so plötzlich die ID herkommt. Man
sollte die Programmierer des FTD fragen, wie so etwas passieren
könnte.

Eigentlich schade, habe ich doch in einer Woche einiges testen können.
Muss mir wohl nun neue R8C/13 besorgen. Dazu die Frage, ob es die ICs
auch in kleinen Stückzahlen gibt ohne Board, ich könnte sie dann
umlöten ( lassen ).
Von dem guten ELMET-Board setze ich z.Z 3 Stück ein. Dazu gibt es den
Prozessor MSC1210Y4 von TI sogar als Muster gratis. Das wäre doch ein
Vorschlag für Fa. Glyn / Renesas. Aber dieser Prozessor hat mir noch
keine Probleme bereitet und läuft seit ca. 1 1/2 Jahren nonstop.
Also liegt das Muster noch in der Verpackung.

MfG Didi

[js222]

Hast Du es mal mit FFh als ID-Eingabe versucht?

Ich will es nicht ausschliessen, glaube aber nicht an einen Fehler in FDT, der flasht nur das was auch im Mot-File steht. Ob da (oder in einem extra File) eine ID drinsteht hängt meines wissens nur davon ab ob man beim Anlegen des Projektes diese Feature auswählt und dann eine ID vergibt.

Rein theoretisch ist noch vorstellbar das beim Flashen solche Fehler bei der seriellen Übertragung auftauchen die unendeckt von jeglichen Checks bleiben und zu einer gesetzten ID führen. Die Wahrscheinlichkeit ist äusserst gering und bestimmt würde Dir das in diesem Leben nur einmal passieren, nicht bei 2 R8C.

Wen der ID-Kram nervt und ihn nicht braucht sollte sich halt anderen Proz. zuwenden, bevor er da unnötig Zeit mit verschwendet. Wie schonmal geschrieben: Ich hatte vor längerer Zeit mal ein Problem damit was sehr wahrscheinlich auf Kommunikationprobleme zurückzuführen war. Dann nie wieder und seid dem hab ich einige Tausend mal geflasht.

Häng doch mal dein letztes *mot (das nachdem das Problem auftrat, also wo eine ID drinstehen müssste) hier an.