Warum Renesas R8C Murks ist

Hallo,

Halbwertszeit: 1 Tag?

scnr,

Steffen

Den Effekt kenn ich von meinem FORTH auf dem MC68HC908GP32 auch: FLASH ist kapriziös, die Schreibroutine kann abstürzen und Firmwareteil mitnehmen. Zudem gibt es im Kleingedruckten des Datenblatts Angaben zum FLASH bezüglich wie oft Schreiben/Löschen die man nach 2x Lesen nicht verstanden hat und die einem nach nochmaligem Lesen verdächtig vorkommen. Der "Memory-Effekt" bei Akkus kommt einem da harmlos vor.

Ein Monitor/System auf dem Chip zur Entwicklung ist eine feine Sache solange er tut. Aber man braucht Sicherheitskopie der Firmware und ein Programmiergerät um Mass-Erase und Neuladen durchführen zu können.

MfG JRD

Das ist natuerlich fuer mich privat nicht akzetabel. Aber auch als Ing in der Firma hilft mir das bei einem aufgeloeteten SMD nicht soviel weiter. Ausserdem stelle ich mir gerade vor einem von unseren Servicetechnikern wuerde beim Kunden soetwas passieren.

Da sind die Atmels doch besser. Auch da kann man sich die Tuer vor der Nase zuschlagen indem man sich den Oszillator wegdefiniert oder den Reset abklemmt, aber das ist dann wenigstens ein bewusster Akt von Bloedheit und man weiss das man selber schuld ist.

Ganz nebenbei fuehrt das natuerlich auch dazu das der begabte Bastler von morgen sich keine R8C CPUs aus alten Sachen ausschlachten kann.

Olaf

p.s: Ich glaub ich frag mal bei Pollin an ob die nicht einen tollen Controller zum testen ihres 16Segment LCDs brauchen das alle Segmente einschaltet. :-)

Das Teil würde im Regelfall "leer" eingelötet und dann incircuit-programmiert. Also ist es nachladbar und im Feld updatefähig. Um die Boards zu testen ( Testsoftware ins RAM laden, oder in der Firmware vorsehen ) bzw. um Rückläufer zu untersuchen braucht man den Zugriff incircuit in den Controller rein ja auch. In der M&T ist mal bei Diskussionsrunde zu automotive der Begriff "Alzheimer-FLASH" gefallen. Aber Rückfrage des Journalisten was das genau sei hat bei den Vertriebsleuten zu eisernem Schweigen geführt.

Ich würde annehmen die kann man auch incircuit programmieren. Das Board muß aber entsprechend ausgelegt sein. Bei Freescale z.B. muß man IRQ-Pin auf 8V anheben. Muß den PA0-Pin hochohmig bekommen sodaß er bidirektional halbduplex die V24 macht. Andere PIns auf GND oder 5V ziehen. Muß alles in der Entwicklung der Hardware berücksichtigt sein, sonst hat man mit eingelötetem FLASH keine Freude.

Man kann bei den Motorola/Freescale auch Bereiche irreversibel ( d.h. nur MassErase hilft ) schreibschützen. Damit verbaut man sich in einem Monitor/FORTH aber die Möglichkeit einfach in der Firmware rumpatchen zu können.

MfG JRD

Weil die Software sonst immer gesagt das man keine ID gesetzt hat und man nicht weitermachen kann.

Mittlerweile kommt es noch besser. Ich hab das mindestens 20 mal probiert und das Programm hat immer gesagt das die ID falsch ist.

Vorhin hab ich es einfach aus langeweile nochmal ausprobiert und diesmal hat er die ID wieder akzeptiert. Ich konnte jetzt die CPU loeschen und auch auslesen, aber nicht programmieren.

Naja, niemand ist nicht richtig. Jemand der die ID geklaut hat schon. Da sind andere Controller besser.

Aber loeschen koennte man doch schon erlauben oder?

Tja, jetzt 'habe' ich sie wieder und ich darf alles ausser brennen.

Welcher Monitor? Und wo soll der sein? Und wo soll dann mein Programm sein? Das ist ja kein dicker M16C

Olaf

Ich hab gerade nochmal ein bisschen rumgespielt.

Ich kann jetzt als ID alles eingeben und der Prozessor wird erkannt, ich kann ihn dann auslesen und loeschen, aber nicht brennen.

Sehr eigenartig!

Olaf

Da stimmt evtl. irgendwas mit Deiner Kommunikation nicht. Hast Du die richtige Baudrate passend zum Quarz?

[...]

Lese gerade, dass Du gar keinen Monitor brauchst, weil der gleich vom KD30 mitgeladen wird.

Der KD30 ist eigendlich das Sahnestück beim Debuggen. Und ich dachte, Du wolltest mal was richtiges ausprobieren. Immer die Application direkt zu flashen ist doch der gleiche Murks wie beim PIC und AVR.

Hier findest Du das Datenblatt

Der R8C/15 hat zwei Address Match Interrupts. Mit dem KD30 kannst Du im Step-Betrieb arbeiten, oder zwei unabhängige Stop-Points setzen. D.h., der KD30 setzt an der Stop-Adresse den Address Match Interrupt und der Monitor wird aufgerufen, wenn der Prozessor auf die Adresse kommt. Mit dem KD30 kannst Du Dir zu jedem Zeitpunkt ansehen, was auf den Adressen steht (RAM oder ROM), Du siehst alle Register und kannst Dir beliebige Variablen (structs, unions, arrays usw.) in's Watch-Fenster ziehen und beobachten. Der KD30 zeigt Dir alles in C-Sourcen Assembler oder gemischt an.

Dirk

Andreas Ruetten wrote in news:729f7$429b696b$508d8e48$ snipped-for-privacy@news1.surfino.com:

Crossworks MSP430 ist gut. Flashed die 60k in ein paar Sekunden. Sogar auf meinem P500. Und der MSP430 verhält sich so wie du das beschrieben hast - laeuft per default immer mit ca. 800kHz. Irgendwelche dämlichen Fuses gibbet nicht (bis auf die Echte, mit der man den JTAG totlegt, da brennt wirklich ne Leiterbahn im Chip durch. Das können aber "zum Glück" nur ein paar teurere JTAG Adapter. :-) (Tja den MSP430 haben halt nicht igendwelche Prozessorleute gebaut, sondern die Analogabteilung von TI (in Freising). Die kannten die Probleme die Du hier schilderst wahrscheinlich alle selbst :-).

M.

--
Bitte auf mwnews2@pentax.boerde.de antworten.

Merkwürdig. Wenn Du Ihn löschen konntest, was willst Du dann auslesen? Wenn Du nicht die richtige ID angibst, dann kannst Du nichts machen.

Hast Du mal versucht den KD30 zu installeren und dich an den R8 zu connecten?

Dirk

Andreas Ruetten schrieb:

(Du plenkst, bitte abstellen.)

Schnellerer Start, ohne zweimal auf einen Oszillator warten zu müssen?

Fuses muss man ja sowieso für allen möglichen Krempel programmieren.

Davon abgesehen, dass sowas ja auch nicht auszuschließen ist.

Lass mich raten, Uralt-Waren an AT90S2343? Hatte ein Kollege auch mal, muss eine Ausschuss-Serie gewesen sein, die Reichelt billig aufgekauft hat. ;-)

Passiert aber bei den aktuellen Chips nicht mehr, seit interner RC-Oszillator standardmäßig auf jedem Controller drauf ist, der ist dann immer voreingestellt.

Vielleicht solltest du dein Windows einfach in die Ecke legen und dich der Welt der Opensource-Tools widmen. Wenn dir dort irgendwas nicht gefällt, kannst du zumindest selbst aktiv dazu beitragen, es noch zu verbessern (oft sind es ja nur Kleinigkeiten).

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Das es dort besser ist glauben wir dir ja gerne, aber das ist ja auch genau die Frage. Ich meine eine Firma welche ICs herstellt sollte doch in der Lage sein wenigstens ein halbwegs zuverlaessiges Programm zu schreiben was damit arbeitet.

Ein weiteres Beispiel fuer die aergerlichen Kleinigkeiten die ich meine: Bei der Software von Renesas muss man ueber einen Haken einstellen welchen Prozessor man hat. Aber jedesmal neu wenn man sein S-Record neue eingelesen hat. Warum kann die sich das nicht merken? Hat der Programmierer davon niemals dreimal hintereinander einen Prozessor gebrannt? Dann waer ihm das wohl aufgefallen.

Schaust du dir dagegen mal das Programm an das jemand selber geschrieben hat

so hat das zwar auch keine luxusdesignte Oberflaeche aber man merkt das es von jemanden geschrieben wurde der wirklich mit den Controllern arbeitet. So jemanden scheint es bei Renesas nicht zu geben.

Olaf

Argh! Es geht darum das die Programmfunktion 'Auslesen' nun funktioniert ob dabei nun etwas sinnvolles rauskommt ist erstmal nebensaechlich. Bis vor kurzem ging da naemlich nur ein Fenster auf das ich die falsche ID habe. Wenn meine ID aber nun zum lesen und loeschen geeignet ist, warum dann nicht zum brennen?

Nein.

Ich habe aber mal die Betaversion 1.40 vom anderen M16C-Flasher

runtergeladen und dort im File einen eintrag fuer den R8 erzeugt. Der kann dann mit dem Prozessor connecten, ihn loeschen und auslesen. Nur beim brennen gibt es sofort nach beginn einen Fehler das ich ausserhab des erlaubten Adressbereichs bin. Nun kann man das nicht ueberbewerten, da die Software halt Beta ist und nicht fuer die R8 gedacht, aber interessant finde ich schon das sie im Fehlerbild uebereinstimmt.

Olaf

Ich mach alles defaultmaessig mit 9600 und das hat ja erstmal 20-30mal funktioniert. Haette es von Anfang an nicht funktioniert wuerde ich den Fehler natuerlich auch eher bei mir vermuten.

Da bin ich mal gespannt. :-) Ich probier es gleich mal aus.

Olaf

Eindeutig. Ich hatte mal einen M16C, der sich so komisch verhielt. Wie sich später herausstellte, war die Spannungsversorgung sehr gestört. Evtl. hast Du ein ähnliches Problem? (Das war übrigens der erste LM317, den ich schwingen sehen hab) Natürlich ging die erste Idee Richtung "Controller defekt" ;-) Sonst frag' mal bei Glyn nach, vielleicht wissen die mehr.

Grüße, Andre

Debugger scheint grundsaetzlich zu funktionieren. Soll heissen er laedt beim starten etwas in den Controller, ich konnte mein Programm reinladen und mit 'GO' starten, und es laeuft dann auch.

Aber der Debugger ist dann nicht mehr zu bedienen und man muss ihn killen. Muss ich von meinem Programm die Kontrolle besonders zurueckgeben? Ich lass es jetzt einfach in das return von main laufen.

Eigenartig finde ich auch das der Debugger seine Firmware jedesmal neu laedt. Ich dachte der schreibt sich in das Flashrom.

So langsam frag ich mich ob die Probleme nicht mit dem USB->RS232 Adapter zusammenhaengen. Aber warum sollte das dann erst funktionieren und dann nicht mehr. Ausserdem gab es nie eine Fehlermeldung die daraufhin deutet. Ich teste auf jedenfall mal mit einer normalen RS232 und berichte dann.

Olaf

Nein, der Verdacht liegt natuerlich nahe wenn man alles kann aber ausgerechnet nicht flashen. Ich hab deshalb extra schon zwei verschiedene Arten der Versorgung probiert.

Olaf

Du musst einen Interrupt-Vektor auf eine Routine im Monitor setzen. Welcher das nun beim R8C ist, weiss ich nicht, sollte aber irgendwo in der Doku stehen. Gut, wenn Du (noch) keine eigene Interrupt-Tabelle setzt, dürfte das entfallen. Wo ich drüber gestolpert bin: Interrupts müssen noch aktiviert werden (fset i). Bei den richtigen Emulatoren von Renesas braucht man das natürlich nicht. ;)

Grüße, Andre

Naja, ich tue hier gerade am 430F149 rum, aber die Begeisterung hält sich in Grenzen. Die Architektur der CPU mag gut sein und die I/O ( Wandler mit guter Auflösung, MAC für Arithmetik ) ist auch gut. Aber MSP430 ist jetzt fast 10 Jahre alt, ein bisschen ausgereifter könnte die Dokumentation und die Fehlerbehebung schon sein. Das Errata-Blatt ist 13 Seiten mit 4 Bugs pro Seite. Beim Bootloader ( 3 Bugs ) z.B. "The bootstrap loader SW cannot program the flash memory, software workaround available" Was der Fehler genau ist und wo man den Patch findet wird einem aber nicht verraten. Ich habe auch nicht den Eindruck, daß die Masken geändert werden, wird wohl munter mit Bugs weiterproduziert. Freescale 68HC08 ist nicht fehlerfrei, aber die Errata mitdenen ich zu tun hatte sind 2 Seiten und wenn man auf die Seriennummer der Chips schaut sind sie meist historisch, d.h. Maske geändert, Bug hehoben.

MfG JRD

Offensichtlich gelingt es dem Debugger Deinen Controller zu flashen!!

Beim M16C ist dass so, dass man die Interrupts der seriellen Ss. auf bestimmte Adressen legen muss (bei Dir im Code). Wenn der KD30 etwas an den Controller über die serielle Ss. sendet, wird dann in den Monitor gesprungen, der antwortet. Ich kann mir aber gut vorstellen, dass das beim R8C unnötig ist, weil der nur eine serielle Ss. hat und somit alles eindeutig ist. Der M16C hat ja 5 Ss. und da muss man dann auch seinen Monitor selbst compilieren, weil der ja nicht wissen kann, welch der seriellen Ss. man verwendet.

Das hätte ich auch erwartet.

Deshalb hatte ich gefragt, ob irgendwas mit Deiner Kommunikation nicht stimmt.

Dirk