R32C geht nicht mehr :-(

[amper]

Hi zusammen,

leider muss ich wohl gestehen das ich irgendwas verbockt habe. Ich habe nun seit ca. einem Monat das USB Board von Glyn und seit heute meint er immer "No match ID" aber ich flashe schon diue ganze Zeit mit der selben ID nämlich "FF FF FF FF FF FF FF" aber auf einmal geht nichts mehr aus der Fehlermeldung.
Habe dann bei Glyn nachgehackt und auch eine Antwort erhalten, (Email im Anhang), leider verstehe ich nur Bahnhof. Ich weis einfach nicht weiter und bitte daher euch um Hilfe.

Ich kann aber mit sicherheit sagen das es nicht daran liegt das beim versuch des Flashens der falsche controllertyp eingestellt ist.

[js222]

Auf jeden Fall als erstes ein Backup des ganzen Projektes
machen. Am wichtigsten ist das mot-File und Dateien in denen Du eventuell was geändert hast z.B. Interrupt Vektoren.
Es muss genau das sein was Du auch als letztes reingeflasht hast, vielleicht lässt sich dann rekonstruieren
ob und u.U. welche ID reingeflasht worden ist.

Das Format eines mot-Files ist kann man googeln, die Adressen der ID stehen im Hardware-Manual. Durch einen Vergleich kann man feststellen ob und was in den ID-Bereich geschrieben worden ist.

Jörg.

[amper]

HI,

also ich habe das programm wieder auf den letzten Stand der Übertragung gebracht und mir dann das fertige mot-File in der HEW angesehen (Disassembler mode) aber an den Stellen laut Datenblatt/Hardeware Manual -> "FFFFFFE8" bis "FFFFFFEE" stehen jeweils nur "FF".
UND NUN ?

Nachtrag:

Wie kann ich dafür sorgen das das nicht nochmal passiert??

[js222]

Also erstmal sollte man vorsichtig sein was ein Programm anzeigt, könnte ja sein das dieser Speicherbereich gar nicht Behandelt wird. Wichtig ist das was tatsächlich im mot-File steht, denn danach wird sich wohl der Flasher richten,
sofern man dort nicht von Hand eine ID vergeben kann.
Ist gut möglich das im mot-File für diesen Bereich nichts vorhanden ist. Dann zeigt die HEW dort sowieso FF an weil das dem Zustand eines nicht beschriebenen Flash entspricht.
Das aktuelle mot-File ist aber auch gar nicht so interessant, sondern jenes was als letztes vor dem Fehler reingeschrieben worden ist.
Ich denke es ist auch gar nicht so wahrscheinlich das in irgendeinem c-Programmfile aus Versehen etwas reingekommen ist was die ID beschrieben hat. Da müsste man schon einiges Anstellen, wenn es denn überhaupt geht.
Wichtiger sind die Assembler Startup-Dateien, ncrt0.a30
und besonders sect100.inc.
Beim R8C war es wohl möglich in der letzteren (hatte etwas anderen Namen) durch einfügen von Interrupts die Vektortabelle so zu verlängern das die möglicherweise die ID überschrieben wurde. Das sieht auf den ersten Blick beim R32C zwar etwas anders aus, aber man kann da wahrscheinlich auch so drin rumkaspern das man das auch hinbekommt.
Hast Du an den Dateien etwas verändert?
Wenn das passiert ist und Du das "kaputte" mot-file nicht mehr hast muss man genau diesen Zustand wiederherstellen und dann ein neues mot-file erzeugen.
In diesem kann man dann sehen welche Daten in den ID-Bereich geschrieben worden sind. Diese ID kann man dann beim nächsten Flashen eingeben.

Die Frage ist aber ob das überhaupt passiert ist, hast Du die Nullen als ID überhaupt schonmal ausprobiert?
Was sagt das Flashprogramm denn wenn gar kein Controller dranhängt oder das Teil gar nicht eingeschaltet ist? Ich hab schon bei anderen Versionen solche "falschen" ID-Fehlermeldungen gesehen.
In dem Fall auch mal an einem anderen Rechner ausprobieren. Manche USB/RS232-Chips (oder besser deren Treiber in Verbindung mit Win) wechseln auch schonmal gerne den Port, probier mal aus ob dann auch eine plausible Fehlermeldung kommt und nicht zufällig was mit "ID".

Im ersten, festgepinnten Thread in diesem Forum stehen auch einige Dinge zum ID-Problem. Wahrscheinlich wird nicht alles auf den R32C zutreffen, da sich alles auf den R8C bezieht, aber vielleicht findest Du noch ein paar Sachen die man noch ausprobieren kann wenn die oben genannten Sachen nichts bringen.

Jörg.

[amper]

Danke schon mal im vorraus für deine sehr umfangreiche Antwort ich werde die von dir angesprochenen Dinge morgen mal aus probieren und dich und die anderen auch wissen lassen wie es aus gegangen ist

Gruß

Alex

[ttom]

Hi, mich hat es jetzt auch erwischt. Kann den KD100 nicht mehr starten, kann auch nichts mehr flashen.. Immer wieder stolpert
man über die bl... ID, 00 und FF bringen nichts. Schade, dass das Ding so sensibel ist... Jemand ne Idee, wie man das Board sicher
wiederbeleben kann ???

Gruß
Thomas

[amper]

HI,

also ich habe dem Board die Marotte jetzt vor erst mal aus getrieben. FRAGT MICH ABER BITTE NICHT WARUM ES NICHT GING, HAB KEINE AHNUNG WAS DER AUSLÖSER DAFÜR WAR.

Auf jeden Fall habe ich das FDT4.02 von der mit gelieferten CD installiert.

1) mot-file mit rechts klick "öffnen-mit" FDT4.02
FDT öffnet sich und es ers cheint ein kleines Fenster
mit dem HEX-File.

2) Im Menü Device -> "Configure Device" anwählen
es erscheint das Fenster "Choose Device and Kernel"
mit dem Scroll-Balken ganz runter und dann
R32C R5F6110 1_0_00 auswählen und mit weiter
fortfahren -> COM-Port wählen -> weiter -> fertig

3) Reset Taster des Boards betätigen dann erneut Menü
Device -> Connect to Device -> Erase Device ->
Button "Select All" betätigen -> Erase
WICHTIG: Nach dem Erase das Board ca. 1-2s von
Spannung nehmen.

4) Jetzt wie gewohnt flashen aber zuerst das Monitor-
programm wieder aufspielen.

Ich hoffe es hilft, wäre aber schön wenn mir bzw. uns mal einer erklären könnte was der Auslöser für das ganze delema war.

Gruß Alex

[amper]

@ Jörg (J222)

ja ich habe an der "sect100" etwas geändert, ich habe sie im Dateianhang hinterlegt wäre nett wenn du dir das kurz anschauen könntest und wenn Dir was auffällt mir bescheid gibst.

nach der Eingabe von :

.glb _ISR_TimerA4
und
.lword_ISR_TimerA4

kam es dann zu diesem Eklat.
Ich verstehe aber nicht warum!!

Gruß Alex

[ttom]

Hallo Alex,

guter Tip ! R32c funzt wieder...!

Thomas

[js222]

Hallo Amper,

Deine Beschreibung wie Du den µC wieder reaktiviert hast deutet eher auf ein Problem mit der Software, Verkabelung oder Betriebsspannung hin.
Oder auch recht wahrscheinlich:
Beim R8C gab es auch solche Seltsamkeiten, insbesondere das man das Board (vermutlich nach einmaliger Eingabe einer falschen ID z.B. 00h anstatt ffh oder umgekehrt) eine gewisse Zeit spannungslos machen musste um einen neuen Versuch zu wagen.
Das würde für die ID-Protction auch sinnvoll sein, sonst könnte man ja automatisiert den ID-Raum durchnudeln und so an das Programm kommen. Die ID soll ja hauptsächlich das Auslesen verhindern, wirkt aber auch für Lösch- und Schreiboperationen.

Ich hab mir die sect100 mal angeschaut, das sieht so schon OK aus.
Schau aber auch mal zur Sicherheit in die ncrt0.a30,
dort findest Du die Zuweisung zu "VECTOR_ADR", der Wert der da steht ist Interessant.

Hintergrund:
Deine variable Vektortabelle (da wo Du ".glb_ISR_TimerA4" und ".lword _ISR_TimerA4" eingetragen hast) hat 256 Einträge mit jeweils einer Adresse (4Byte), ist also 1024 Byte lang. Ab Adresse 0xFFFFFFDCh beginnt die fixe Vektortabelle und in dieser
liegen nicht nur Interruptvektoren sondern auch die ID.

Wenn nun "VECTOR_ADR" genau auf eine 1024 Byte niedrigere Adresse zeigt und die Vektotabelle genau 256 Einträge hat ist alles OK. Falls aber "VECTOR_ADR" zu hoch ist oder die Tabelle zu lang, könnte ich mir vorstellen das am Ende die ID ganz oder teilweise mit irgendeiner Einsprungadresse überschrieben wird.
Das kann leicht passieren durch hinzukopieren von Zeilen aus anderen Programmen und vergessen eine entsprechende Anzahl von Zeilen herauszukommentieren
oder zu löschen. Vorsicht! Man muss unterscheiden zwischen den Zeilen die mit .glb beginnen und denen die mit .lword beginnen, letztere sollten die Zahl von 256 nicht überschreiten. glb-Zeilen dürfen wohl zusätzliche drin sein.

Aber wie schon geschrieben, sehr wahrscheinlich ist dieses Scenario nicht der Fall gewesen, sonst hättest Du
das Teil wohl nicht so "einfach" wieder reaktiviert bekommen.

Jörg.