Schon wieder: ID Check

Postby stef16 » Thu May 31, 2007 12:00 am

@ JS222

Nein, natürlich würde ich das nicht von Hand machen wollen. Es kommt mir darauf an, wo es automatisch gemacht wird.

Bei anderen µC passiert auch viel Mist z.B. mit verbrutzelten Fuses. Da hat aber der Anwender mitgewirkt. Das hat eine andere Qualität als ein Verbrutzeln mit einer MOT-Datei bzw. das Anlegen der ID im Flash. War nicht mehr genug Geld da für eine besser geschützte Position?

Ein Rasiermesser im Haus haben (per ID sperren können) ist was anderes als ein Rasiermesser offen rumliegen lassen.

Gruß
Stefan
stef16
 
Posts: 84
Joined: Fri Jan 03, 2014 1:50 pm

Postby js222 » Thu May 31, 2007 12:00 am

Hallo Stef16,

in diesem Fall (mot-Datei von lamken) scheint es aber nunmal so zu sein dass durch eine editierte (von wem auch immer) sect30.inc Datei sich die Vektoren in den Bereich der IDs verschoben haben.
Dafür dem Hersteller die Schuld zu geben fände ich etwas weit hergeholt (auch wenn es mir noch schleierhaft ist wieso ein auskommentieren von Vektoren diese ausgerechnet nach oben verschiebt).

Natürlich kann man ein System sehr handhabungssicher machen, ob es dann noch flexibel genug ist muss jeder für sich entscheiden. Die Dinger (von jedem Hersteller) sind für die Industrie gebaut, für Firmen die möglichst Millionen davon abnehmen sollen, wenn da bei der Entwicklung ein paar µCs bei draufgehen juckt das keinen. Niemand denkt dabei an Hobbyisten die sich mit dem Kram rumschlagen müssen, Beschaffungsprobleme und sehr enges Budget haben.
Das ist nunmal leider so, bei einem Chip ist jenes Feature gut gelöst bei einem anderen machts Ärger und umgekehrt. Den idealen µC für jeden wird es nie geben.

Ich arbeite seit 3 Jahren mit M16Cs und musste noch keinen in die Tonne kloppen.
Jedenfalls nicht wegen ID-Problemen ehre wegen den Fehlern zwischen den Ohren

js222
 
Posts: 183
Joined: Fri Jan 03, 2014 1:48 pm

Postby frankl » Thu May 31, 2007 12:00 am

Hallo lamken,
Deine Test7_DCF77 hat einen kleinen aber feinen Fehler. Du hast die Interrupt Tabelle modifiziert und jetzt 2 Vektoren 29. Damit ist die Tabelle nicht mehr 256 Byte, sondern 260 Byte.
Und da die Tabelle bei 0xFEDC anfängt überschreibt jetzt der letzte Vektor der Section vector den ersten Vektor der section fvector. Da aber die Vektoren aus fvector alle auskommentiert sind (bis auf RESET) fällt das nicht auf. Mit dem Überschreiben des ersten Vector wird dann auch das erste Byte der ID überschrieben, wie JS222 schon gesagt hat.

Gruß

Frank
frankl
 
Posts: 125
Joined: Thu Jan 02, 2014 10:42 am

Postby js222 » Thu May 31, 2007 12:00 am

Hallo FrankL,

Du hast recht, nach entfernen der Tomaten sehe auch ich einen Vektor zuviel. Hat also nichts mit den Auskommentierten zu tun sondern vermutlich damit das mittels rüberkopieren aus einer anderen sect30 ein ganzer Block hinzugekommen ist.
Von dem sind zwar die meisten auskommentiert aber insgesamt ist es einer zuviel.
Damit ist auch nichts mehr schleierhaft und dieser ID-Fall geklärt.

js222
 
Posts: 183
Joined: Fri Jan 03, 2014 1:48 pm

Postby didi5 » Thu May 31, 2007 12:00 am

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
didi5
 
Posts: 230
Joined: Fri Jan 03, 2014 1:48 pm

Postby js222 » Thu May 31, 2007 12:00 am

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.

js222
 
Posts: 183
Joined: Fri Jan 03, 2014 1:48 pm

Postby didi5 » Thu May 31, 2007 12:00 am

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

Grüsse Didi
didi5
 
Posts: 230
Joined: Fri Jan 03, 2014 1:48 pm

Postby nikola t. » Thu May 31, 2007 12:00 am

Ich glaub nicht, da ich keine Interrupts ver wendet habe.
Ich habe nur eine Abfrage vom Port1.1 mit einem IF gemacht nicht mehr.
Mit den Interrupts habe ich mich noch nicht herum gespielt.
nikola t.
 
Posts: 4
Joined: Fri Jan 03, 2014 1:51 pm

Postby didi5 » Thu May 31, 2007 12:00 am

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
didi5
 
Posts: 230
Joined: Fri Jan 03, 2014 1:48 pm

Postby stef16 » Thu May 31, 2007 12:00 am

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
stef16
 
Posts: 84
Joined: Fri Jan 03, 2014 1:50 pm

PreviousNext

Return to Das R8C-Projekt

Who is online

Users browsing this forum: No registered users and 1 guest