Schon wieder: ID Check

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

Wieso taucht die ID in der MOT-Datei überhaupt auf? (*)

Mir leuchtet ein, dass man eine ID über das Flashwerkzeug setzen kann (quasi interaktiv).

Aber ein Einkompilieren in die MOT-Datei nicht. Auf diese Weise wird ein Übernehmen von fremden Binärcode (d.h. fertigen MOT-Dateien) zu einem echten Risiko für den eigenen R8C...

Welche Anweisungen im Compiler bzw. Einstellungen/Maßnahmen der HEW führen dazu, dass Schreibanweisungen für die ID-Positionen in MOT-Datei übertragen werden?

Gruß
Stefan

(*) Add:
Der Debugger könnte hier eine Rolle spielen, weil er einen Vektor verbiegen muss. Daher auch meine Frage vorher.
stef16
 
Posts: 84
Joined: Fri Jan 03, 2014 1:50 pm

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

Hallo,

ich habe mir die letzten Beiträge zum ID Check Problem durchgelesen.

Ich werde nämlich seit einem Absturtz während des Flashens aufgefordert eine ID einzugeben. - 000.. und FFF..., Board ohne Strom, anderer PC und anderes Flash Board hat alles nichts geholfen. - Meine Hardware hab ich mit dem Board eines Freundes übrigens testen können, die funktioniert.

Ich werd jetzt wohl 30 Euro investieren müssen. Einzeln bekommt man die Boards ja nicht.

Alles sehr ärgerlich.


r8c_ivan
 
Posts: 3
Joined: Fri Jan 03, 2014 1:50 pm

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

@ Stef16,

ID in der mot-Datei kann durchaus sinnvoll sein, oder würdest Du bei einer Serie von ein paar Hundert das Eingeben von Hand (und die dabei garantiert auftretenden Eingabefehler) mitbezahlen wollen?

In der HEW gibt es die beschriebene Möglichkeit beim Anlegen eines Projektes, steht ja auch in der Anleitung von Elektor das man hier ein kreuzchen an der richtigen Stelle machen muss, was passiert wenn man eine der anderen Optionen (Automatic, Interactive) auswählt habe ich noch nicht ausprobiert, wenn ich mal einen Proz übrighabe mach ich das mal .
Beim Compiler (Assembler AS30), wenn ich mich recht entsinne, gibt es eine Kommandozeilenoption mit der man entweder direkt oder über eine Dateiangabe die ID übergeben kann. Oder man gibt über eine Anweisung den Code im Programm ein und es wird dann ein ID-File (*.id) ausgespuckt.
Vielleicht gehts sogar indem man den absoluten Adressen im Source einen Wert zuordnet.
Wäre mal Interessant zu wissen ob ein solches bei den Leuten mit ID-Problem irgendwo herumspukt, die könnten es dann ja mal mit der enthaltenen ID versuchen.

In FDT hab ich übrigens bisher nichts gefunden wo man eine ID vergeben könnte, der fragt halt danach wenn er eine ID im µC findet. Könnte aber sein das er zur Eingabe auffordert wenn man in der HEW eine der beiden Protection-Optionen ausgewählt hat, glaub ich aber nicht.

Und natürlich ist das übernehmen von irgendwelchen Binärfiles ein Risiko, das hat auch überhaupt nichts mit dem R8C zu tun. Ich würde mich nie auf irgendeinen Kram anderer verlassen, was ist zum Beispiel mit einfachen I/O Einstellungen: Da definiert einer was als Ausgang an dem noch der Ausgang eines Teils vom vorherigen Projekt liegt, und das wars dann, zumindest für den Port.

@ R8C_Ivan:
Wieso 30 Euronen? Ein R8C kostet doch keine 30, das Umlöten ist nicht wirklich ein Problem wenn man dabei vorsichtig vorgeht. Anleitungen zum SMD-Löten gibts im Netz einige.
Was meinst Du mit "anderem Flash Board"?

Aber bitte lies auch mal die Beiträge aus der "Anfangszeit" da sind einige Tips dabei die Du vielleicht noch nicht ausprobiert hast, das meiste ist im µC-Forum zu finden da es dieses "damals" noch nicht gab.
js222
 
Posts: 183
Joined: Fri Jan 03, 2014 1:48 pm

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

@lamken:

hab mir nochmal einige der Projektdateien angesehen,
was auffällt:
Die vector Angabe in der map-Datei ist sonst immer bei 100, bei dem Test_DCF77 auf 104. In der sect30.inc ist eine Menge der Vectoren auskommentiert.
Ob (und wie) das Zusammenhängt müsste man noch näher betrachten, es scheint aber so zu sein das ein Vector in den ID-Bereich reinragt.
Würde auch mit dem Inhalt des S-Records zusammenpassen.

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

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

Hallo JS222,
versteh mich bitte nicht falsch, die Beiträge hab ich fast alle gelesen. Der allererste flash hat auch o.B. bestens funktioniert. Es handelte sich hier um die Muster-mots, jingle bells und port_toggle von der Glyn CD. Wenn das dritte Muster-mot lcd sich nicht mehr flashen lässt obwohl die hardware ok ist dann sollte man schon nach der Zuverlässigkeit fragen dürfen zumal ich 3x compis 3x os und die rs232 als real und usb-adapter vergebens ausprobiert habe. Zum compiler bin ich noch gar nicht gekommen.

Interessant wäre zu erfahren ob ein aufwendigerer realtimedebugger Einsatz (z.B E8 oder höher) zum resetten geeignet wäre?
Ich werde den thread weiter mit Neugier verfolgen.

Gruß
gfx2
 
Posts: 2
Joined: Fri Jan 03, 2014 1:51 pm

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

Hallo gfx2,

nein ich verstehe Dich nicht falsch, ich weiss sehr wohl wie frustrierend das sein kann und das man sich nicht durch hunderte Seiten Doku und FAQs und Forumsbeiträge durcharbeiten will um weitermachen zu können.

Aber sei mir nicht böse, ich kann auch nicht jedem alle Möglichkeiten aufs neue heraussuchen. Man kommt um das aufmerksame Lesen der alten Beiträge und der FAQs kaum herum wenn Probleme auftreten.


Es wäre bestimmt sinnvoll nochmal alle relevanten Beiträge zusammenzufassen, in den FAQs fehlt vielleicht noch das eine oder andere.
Z.B. die Information das es nur mit einem Parallelprogrammer möglich ist die ID zurückzusetzen, dies ist auch in einem der frühen Threads zum ID-Fehler gesagt worden.
Ich hab nur leider im Moment auch nicht die Zeit und den Nerv mich da mal ranzuzusetzen.

Dein Problem könnte übrigens eher in die Kategorie "Programm läuft nur einmal" passen, schau dort mal nach Tips.
Ein ID-Fehler muss nicht zwangsläufig heissen das wirklich eine ID gesetzt worden ist, meist scheint es was anderes zu sein, sonst wären nicht einige R8Cs "wiederbelebt" worden.
Ich bin ziemlich sicher das es weniger mit einem schrottigen mot-File (aufgrund eines schrottigen sect30.inc Files) zu tun hat.

Um sicher zu gehen kannst Du das letzte was reinging ja mal hier dranhängen, ich schau dann mal rein.

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

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

PreviousNext

Return to Das R8C-Projekt

Who is online

Users browsing this forum: No registered users and 1 guest