Schon wieder: ID Check

[didi5]

Habe sie Dir gestern als email geschickt.

MfG

Didi

[powermann]

Hallo hat es schon einer versucht den Microcontroller über längere Zeit mit einer ganz kleinen negativen Spannung zu speisen?

Wie klein sie sein soll weiss ich nicht. Vielleicht machen so 0.5-0.8 Volt dem Controller nichts aus?
Wer kennt sich damit aus?

Vielleicht löscht es so den ID-Inhalt schneller.

[pistnor]

Ich habe das selbe Problem
Nachdem beim 1.Board das mit ID Check angefangen hat hab noch eins bestellt. Das hat dann funktioniert. - ca 20 mal flaschen dann wieder id check ??? Niemals hat was nachgefragt ob ich einen id code setzen will.

[h.d.]

Hallo R8C Fans
Nachdem im Forum zwischen 2007 und 2010 relative Ruhe zu diesem Thema war, möchte ich hier mal nachfragen ob es mittlerweile neue Erkenntnisse zur Wiederbelebung von ID Check Error betroffenen Chips gibt.
Derzeit habe ich drei Chips mit darauf befindlichen Originalprogrammen der Elektor CD aus dem Buch (lcd , port toggle und interface). Diese Programme werden auch ausgeführt. D.h. die Chips sind nicht grundsätzlich defekt.
Aber beim Flashen neuer Versionen kommt es immer zu diesem "dämlichen" ID Check Error.
Die Chips laufen auf dem Original Elektor Applikationsboard und der Original Elektor SW (HEW und FDT). Flashen mit dem MC_16C Flasher verursachen die gleiche Fehlermeldung.
Alle Tips zur Wiederbelebung aus dem Forum habe ich bereits erfolglos ausprobiert.
Hat vieleicht jemand neuere Informationen zur "Wiederbelebung"?

Im Voraus vielen Dank
Hein 2912

[pistnor]

Ich habe auch schon 2 RC8 boards herrumliegen mit dem 3. traue ich mich nicht mehr was zu probieren .
Schön langsam wird es zeit, dass sie jemand von Elektor um das Problem kümmert - ich möchte nicht mit Gewährleistungsansprüchen argumentieren, aber moralische Verpflichtung sehe ich da schon.
Holt uns endlich da raus!
oder könnt ihr selber nichts machen?
Dann bitte eine Meldung - dann vergessen wird den R8 für immer,
und können aufhören uns herumzuärgern.

[herch]

Bei 2 meiner R8C/13 Boards wird nun auch der "ID Check" verlangt.

Es fing damit an, dass bei einem Board Probleme beim Flashen auftraten und die übertragene Software fehlerhaft war. Nach einem Neustart vom FDT konnte man den R8C/13 wieder ein paar mal flashen, dann wurde wieder nur fehlerhafte Programme übertragen - bis plötzlich der "ID Check" kam. Ich startete den Rechner neu und probierte einen weiteren R8C/13 der sich einmal problemlos flashen ließ, dann kam auch der "ID Check". Die übertragene Software ist fehlerhaft.

Ich habe gestern versucht mit Renesas in Kontakt zu treten und und füllte ein Formular mit der Problemschilderung auf deren Homepage aus. Die Antwort kam schneller als erwartet:

Your message has been enqueued and undeliverable for 24 hours
to the following recipients:

Recipient address: technical.inquiry.eu@rtemail-hub.rte.renesas.com
Original address: technical.inquiry.eu@renesas.com
Reason: unable to deliver this message after 24 hours

Mittlerweile haben 6595 Nutzer die Beiträge zu "Schon wieder: ID Check" gelesen. Es wird langsam Zeit, dass man seitens Elektor endlich eine Lösung für dieses Problem findet.

[ibjung]

Hallo!
Alle R8C Nutzer welche den ID Fehler bekommen, bitte ich mal um euere Aufmerksamkeit.

Es geht in diesem Falle um den Transistor-Kennlinienschreiber aus 02/2009. Ich hatte auch alle die in diesem Forum beschriebenen Effekte mit dem R8C auf dem (R5F21134) Controllerboard.

Um es kurz zu machen, ich habe eine mögliche Lösung des Problems gefunden und kann nun wieder beliebig flashen.

Was ist NEU und wurde (glaube ich) hier noch nicht geposted?

Ich habe herausgefunden, dass ähnlich wie bei den EPROM's die baud rate beim programmieren von erheblicher Bedeutung ist.
So kann eine zu langsame Einstellung und eine zu schnelle Einstellung zu Funktionsstörungen während der Programmierung führen. Dieses Verhalten konnte ich bei dem R8C nachweisen. Ausgereifte gute Systeme (Prommer) haben diese Probleme in der Regel nicht. In den 80er Jahren habe ich damit umfangreiche Erfahrungen in meinem Beruf gesammelt.

Was muss man nun tun?
Die Standard baud rate ist [9600baud,8 data bits, no parity, 1 stop bit, kein Protokoll handshake], dabei treten die Fehler auf.
Eine höhere baud rate 19200 oder 38400 funktioniert einwandfrei. Zusätzlich Hardware handshake aktivieren.

Vorgehen:
- zuerst die PC Schnittstelle einstellen wie zuvor beschrieben (38.400, hardware handshake)
- flashsta.exe (V2.3.0.4) starten, dann M16C/80 boot loader und die am PC gewälte COMx Schnittstelle vorwählen
- im flashstarter dann die Schnittstelle auf die neuen Parameter einstellen und dann die *.mot Datei mit der Vorwahl "internal flash memory" laden. Dabei auf die nachfolgende Vorgehensweise bezüglich der einzugebenden ID achten.

Ich habe verschiedene Hinweise aus dem Forum zum ID Fehler genutzt.
1) Ein neuer R8C hat die ID 00,00,00,00,....
2) nach dem flashen, scheint ein bug in der Software dafür zu sorgen das der R8C wieder erreichbar ist wenn man folgende ID Muster ausprobiert:
00,00,....00,00 (neuer Chip, kein flash)
FF,FF,.....FF,FF (nach einwandfreiem flash)
Chip geflashed, aber nun kommt ID-Fehler
00,FF,.....FF,FF
FF,00,....00,00
FF,FF,.....FF,00
00,00,....00,FF
Hintergrund: am Anfang oder Ende der ID Folge ist durch einen bug in der Software vermutlich eine 0x00 oder 0xFF beim flashen eingetragen worden. Ich konnte damit einen R8C wieder ins Leben zurück holen.
3) Bitte verwendet FlashStart Version 2.3.0.4 (download bei RENESAS)

Ich hatte nach 2009 kein flash programm mehr durchführen können. Nun klappt es wieder beliebig oft.

Bitte berichtet mal euere Erfahrung, ob sich die Vorgehensweise als allgemeines Rezept etabliert oder nicht.

Da wir ja auch RENESAS nahe Profis im Lager haben, verstehe ich jedenfalls nicht, warum sich diese nicht zu dieser Problematik äussern. Worauf lässt dieses Fehlverhalten beim programmieren wohl schließen, wenn wir mal davon ausgehen, dass es nicht nur ein Software bug alleine ist? Na wer hat eine Vermutung?

[pistnor]

Hi IBJung
Ich habe zwar FDT 4.08 und 3.4 verwendet da 2.3.0.4 nicht mehr aufzutreiben war, aber dein Trick hat nichts genutzt. Sollte es wirklich an der Version von flashsta liegen? Kann jemand über Erfahrungen mit diesem Trick berichten ich habe 3 Stück ID-Leichen herumliegen.
Kann mir jemand 2.3.0.4 mailen?

Vielen Dank
muellner@inode.at

[stinkywinky]

Ich hatte auch dieses Problem. Die Ursache lag an einer fehlerhaften Interruptvektorentabelle (1 Eintrag zu viel). Dies führt dazu, dass ein ID-Code von 00 FF FF FF FF FF FF gesetzt ist. Pro Vektor, der überzählig ist, wird eine 00 von links eingeschoben.

Zusätzlich hatte ich noch den WDT Interrupt bei den fixen Vektoren definiert. Dabei werden 4 Bytes an Adresse FFF0 abgelegt. Blöd, dass das Byte an FFF3 Bestandteil des ID-Codes ist.

Mein gesuchter Code war nun 00 FF FF FF 00 FF FF

Um das Problem mit den fixen Vektor zu lösen:

WDT:  .addr  _INT_WDT; 3 byte address of WDT ISR  .byte  0FFh       ; 1 byte of ID Code, FFh = not used

[ag]

Bitte berichtet mal euere Erfahrung, ob sich die Vorgehensweise als allgemeines Rezept etabliert oder nicht.

Nach fast 7 Jahren habe auch ich die R8C/13 Weihnachtsgeschenk von Elektor mir angenommen. Auch ich bin sehr prompt auf das allseits beliebte ID Problem gestossen. Ich habe alle vermeintliche Lösungen ausprobiert (allerdings habe ich meine R8C bis jetzt nur eine 1/2 Tag ins Alu-Gefängnis verbannt; längere Strafzeiten werden folgen), bis jetzt ohne Erfolg.

Ich habe aber etwas bemerkt, was hier bisher noch nicht erwähnt wurde (nur am Rande angedeutet). Aus alles was ich bisher gelesen habe, habe ich mir folgendes zusammen gereimt: ich bin opfer der automatische Updates gefallen. Nachfolgend die Rekonstruktion:

1) Software vom CD nach Vorgaben zu installieren versucht. Fehlanzeige (läuft nicht auf 64-bit Rechner) Auf Downloadseite von RENESAS gesucht, gefunden, 64-bit Version Installiert, inklusiv Autoupdate

2) USB zu RS232 Adapter bestellt, Schaltung aus Heft 12/2005 nachgebaut.

3) USB zu RS232 erhalten und angeschlossen, FDT gestartet, Projekt angelegt, port_toggle.mot geladen.

4) Jetzt Flashen - uhh. wie? Es gibt kein "Program Flash" im Menü! Aha! Jetzt heisst es unter Project->"Rebuid Image" bzw. "Download Image". Es klappt! Binkende LEDs!

5) Nun zum jingle_bells. Datei geladen, Rebuild, Download, klappt, aaaber... nur "Jingle bells, jingle bells, " . . . und weiter? Nichts. Reset Taster - "Jingle bells, jingle bells, . . ." Da stimmt was nicht :-|

6) Zurück zu port_toggle. Rebuild , Download. Läuft. Hmmm.

7) Versuche es doch noch mal mit jingle_bells. Äh-ähh. Das Schreckengespenst der R8C: ID Fehler (

Was habe ich gemacht?: NICHT VORHER GELÖSCHT!!! Im Artikel stand dass beim "Program Flash" zuerst gelöscht wird, dann neu geflashed. Die neue Version mit "Download Image" tut genau das und nichts mehr. Unter Device findet man (zu spät) "Erase FLASH Blocks". Grrrrr! Das erklärt warum jingle_bells verstummelt war - 2 Images übereinander geklatsht! Jetzt habe ich ein R8C was vermutlich für immer bestenfalls LEDs blinken lässt.

Na ja, vielleicht sollt ich ins Gefängnis fürs nicht ZUERST nach Problemfälle im Forum suchen. Aber ich veruche erst mein R8C mein Strafe absetzten zu lassen. Vielleicht hilft das.

Kann es sein, das auch andere diese Fehler machten, ohne es zu wissen (oder es zu zu geben)?