|
Anzeige
|
UPD70F3380M2 von RenesasHallo zusammen, hat jemand tiefergehende Erfahrungen mit diesem Teil? Es geht um das Kopieren des Inhalts. Es soll ein 1:1 Klon erstellt werden, was anscheinend nicht funktioniert. Frage: Weiß jemand, ob es da noch spezielle Bereiche gibt, die man zusätzlich berücksichtigen muss? Außerdem wäre interessant zu wissen, ob der Chip eine eingebaute "verify-function" besitzt. Danke schon mal vorab für eure Hilfe Im User Manual des V850ES/Fx3 wird ausführlich erklärt was der "Flash Programming" Mode bzw. das N-Wire Debug Interface kann. Mit beiden kann man den Chip auslesen falls der entsprechende Ausleseschutz nicht aktiviert ist. Programmieren kann man den Chip darüber ebenfalls. Und der "Flash Programming" Mode hat auch ein Verify Kommando, das steht ebenfalls im User Manual. Nachtrag: Wenn man den Chip kopiert sollte man die Flash Mask Options nicht vergessen und berücksichtigen dass es neben Code Flash auch noch Data Flash gibt. Das hier sollte hervorgehoben werden:
Eine wesentlich sinnvollere Ergaenzung des Beitrags von Dieter S. schrieb im Beitrag #7680299: waere gewesen, dass der
ueblicherweise mit einem FTDI USB-Seriell-Adapter bedient wird. :) Der Aufwand sich den selbst zu stricken, ist also ueberschaubar. Die Details kann man sich bei den Renesas Evalboards abguggn. Und was hilft das, wenn beim "Original", das kopiert werden soll, der Ausleseschutz aktiviert ist? Daß er aktiviert ist, ist bei einem kommeerziellen Produkt mehr als wahrscheinlich. Es besteht hier kein Ausleseschutz Gut, wenn das sichergestellt ist ... dann viel Vergnügen beim Klonen. Dolly lässt grüßen.
Dann beschreibe halt wo das Problem liegt. Wenn man Code Flash und Data Flash kopiert sowie die Protection Settings berücksichtigt dann sollte man alles haben. Mit der Renesas Software (z.B. Flash Development Toolkit) ist das kein großes Problem, sowohl per UART ("Flash Programming" Mode) oder per N-Wire Debug Interface. Der Hinweis bezüglich "Flash-Mask-Options" ist interessant. Könnte vielleicht ein Lösungsansatz sein. Ich werde das prüfen. Erstmal herzlichen Dank für eure schnelle Ideen-Hereingabe Wo finde ich denn Informationen zu dem besagten Eval-Board? Es scheint obsolet zu sein. Weder bei Renesas selbst, noch einschlägigen Quellen (Digikey, Mouser etc.) finde ich Infos. Speziell der FLMD0-Pin ist mir unklar. RESET könnte auch wichtig sein, wenn während der Bearbeitungsphase ein Reset initialisiert werden muss (ansonsten könnte man da einen Reset-Generator-Chip dranhängen). TXD und RXD sind klar. Wo kann ich ein Schematics vom betreffenden Bereich des Eval-Boards finden? Oder falls es eine Direktzuordnung zu einem RS232-Pin gibt: welchen Leitungen müssen FLMD0 und RESET zugeordnet werden? Danke für eure Hilfe! Beschreib doch mal genau was das Problem ist, kannst Du den Chip nun lesen oder nicht? Im ersten Beitrag klingt es so als ob die neu programmierte Kopie nicht funktioniert. Im User Manual des V850ES/Fx3 auf Seite 319 ist ein Diagramm das erklärt was mit dem Pins beim "Flash programming mode" passieren muss. Und für den UART Mode muß der FLMD0 Pin lediglich auf "High" gesetzt werden (und bereits beim Reset "High" sein). Ich konnte den Chip mit zwei verschiedenen Programmern (Elnec BeeProg2 und Algocraft uISP) im CSI-Modus ansprechen und auslesen. Der BeeProg2 konnte ihn nicht programmieren, der Algocraft schon. Auslesen konnten ihn beide - aber die Binaries waren nicht die gleichen. Aber jeder Programmer lieferte beim erneuten Auslesen immer das gleiche Ergebnis. DerAlgocraft hat lediglich ein Flash- und ein EEPROM-Binary rausgeworfen - kein Zugriff auf Flash-Mak-Options. Ich konnte Flash und EEPROM Binary auch erfolgreich zurückprogrammieren und der mandatory Verify nach dem Programmieren war erfolgreich - allerdings tat der Chip nicht mehr was er sollte. Der Algocraft erlaubte aber kein "einfaches Verify" eines programmierten Chips - die Funktion "verify" ist in der Soft ausgegraut. Nur in Verbindung mit Write wird automatisch ein Verify angehängt. Jetzt versuche ich ihn mit der Original Renesas-Soft zu bearbeiten - die möchte aber UART-Kommunikation. Ich arbeite auch lieber mit Linux als mit Windows - es gibt ja auch eine Linux-Version der Programming-Soft (RFP_CLI_Linux_V31500_x64.tgz). Die habe ich schon mal ohne angeschlossenen Chip untersucht und festgestellt, dass die Soft Optionen für Write und Verify enthält, aber keine für Read. Dieser Chip und seine Soft unterscheidet sich schon deutlich von allem womit ich es bisher zu tun hatte ;)
da hätten dann aber schon die Warnlichter angehen sollen. Hast du die Abweichungen mal näher angeschaut?
ohne Read kein Verify. Vermutlich werten die nur den WriteStatus bweim Programmieren aus. Wenn es mit den beiden Programmern Probleme gegeben hat: was spricht dagegen die Renesas Software zu verwenden? Für den V850 ist das der "Renesas Flash Programmer". Im UART Mode reicht ein USB auf UART Interface für RXD und TXD, FLMDO legt man auf "High" und "Reset" kann man im einfachsten Fall manuell mit einem Pulldown auslösen. Das funktioniert, ich habe das schon öfters so gemacht. Das ist zwar nicht die ideale Lösung wenn man das Ganze sehr oft machen muß, für ein paar mal geht es aber. Danke Dieter! Genau so werde ich das jetzt machen. Ich habe hier schon diese Software von Renesas vorliegen: Renesas_Flash_Programmer_Package_V31500-doc.zip . Die RFP_CLI_Linux_V31500_x64.tgz (RFP steht vermutlich für Renesas Flash Programmer) ist angeblich die gleiche Soft für das CLI unter Linux - nur kann die nicht auslesen. Ich hoffe die Win-Software kann das - ich werde es testen. @Thomas: "die" ist dann Renesas. Das ist eine der möglichen Programmiersoftwares für den V850 - für Linux. Windows habe ich nur in einer virtuellen Maschine laufen und ich nutze es nur wenn es gar nicht anders geht... Na klar sind die Warnlampen angegangen! Die EEPROM-Binaries waren bei den beiden Programmern identisch, die Flash-Inhalte nicht. Ich habe keinen interpretierbaren logischen Bezug zwischen den beiden Versionen gefunden. Aber wenn ich mit einem Programmer auslese bekomme ich identische Binaries, so oft ich es auch mache. Nur zwischen den beiden gibt es halt Unterschiede. Aber nicht sowas wie Blöcke mit 0x00 oder 0xff, sondern wilde Bytefolgen, aber eben total verschieden. Ich tippe darauf, dass der BeeProg2 im ISP-Modus (CSI) fehlerhaft arbeitet. Der Algocraft Programmer macht da einen wesentlich vertrauenswürdigeren Eindruck.
Ich habe erst vor Kurzem mit dem "Renesas Flash Programmer V2.05.03" einen V850ES/Fx3 mit der weiter oben beschriebenen Methode ausgelesen, das hat funktioniert. Die neuere Version kann das vermutlich ebenfalls. Die neueste Version 3.15 unterstützt den V850 nicht mehr. Ich habe mir die 2.05.03 runtergeladen, die es leider nicht für Linux gibt...
OK, dann war das wohl auch der Grund warum ich die ältere Version für den V850 verwendet habe. Die neuer Version braucht man für die RH850, die die ältere Version nicht unterstützt. Die MCU schafft mich noch... Mit dem UART-Mode bekomme ich keine Kommunikation hin - was ich auch mache. Die beiden Programmiergeräte die ich bisher benutzt habe (BeeProg2 und Algocraft uISP) nutzen beide den CSI-Mode (kein HS) - damit konnten beide die MCU ansprechen und Daten auslesen (zumindest irgendwie, weil beide zwar in sich konstante aber untereinander unterschiedliche Binaries erzeugten). Die herausgeführten Leitungen und deren Zuordnung müssen also stimmen. Also habe ich mir einen Renesas E1 Adapter beschafft. Der ist auch in Ordnung (Selbsttest läuft einwandfrei durch). Ich habe ihn mit der MCU verbunden wie folgt: MCU E1FLMD0 | 4 FLMD0 SCK | 1 SCK SO | 7 SI ?? SI | 5 SO ?? GND | 12,14 GND Reset | 10,13 Reset Vdd | 8 Vdd Etwas unklar ist für mich die Verbindung der beiden Datenleitungen. Nach angehängtem Foto aus der Renesas-Application-Note zur Verbindung E1-->V850ES/FX3 sollen da zwei Ausgänge und zwei Eingänge miteinander verbunden werden, was sinnfrei ist. Ich habe folglich erstmal angenommen, dass die Namensgebung aus Sicht des E1 korrekt ist und Eingang E1 mit Ausgang MCU (und umgekehrt) verbunden. Die Kommunikation der Software RFP V2.05 mit dem E1 klappt auch - aber die Kommunikation mit der MCU schlägt fehl (keine Rückmeldung via FLMD0). Die Algocraft Software kommuniziert mit einem Clock von 2MHz mit der MCU, das habe ich auch bei der Renesas-Soft eingetragen. Dann will die Renesas-Soft noch die Quarzfrequenz der MCU und den Multiplier wissen (wozu? Der Algocraft braucht diese Infos nicht). Der Default von 6MHz Quarz ist falsch - bei meiner PCB ist ein 8MHz Quarz verbaut. Ich habe den Multiplier daher von Default 8 auf 6 reduziert um die gleiche Taktfrequenz zu bekommen. Was ich auch mache - ich bekomme aktuell mit der Renesas-Software V2.05 und dem E1 Adapter keine Kommunikation mit der MCU zu Stande. Die Algocraft Software mit dem Algocraft Programmer (darauf habe ich noch Zugriff) läuft. Ich würde ja gerne die "Option Bytes" kennen - ebenso würde es mich interessieren ob man (analog zu den STM32) auslesen kann ob und wenn ja welche Blöcke geschützt sind (Read-Out bzw. Write Protection). Nur finde ich in der Algocraft Software dazu keine Option. Da gibt es eine ominösen "Volatile Area" mit einer Größe von 0x200 - da sind aber nur Nullen zu finden. Meine Fragen sind jetzt wie folgt: Nutzt jemand den E1-Adapter mit der Renesas-Soft? Bis auf die Datenleitungen bin ich mir sicher, dass die Verkabelung korrekt ist (Ich kann auch Vdd und Reset nachmessen, sind beide da). Ist es ein Hardwarefehler oder bediene ich die Software falsch (Quarzfrequenz/Multiplier?) Wenn ich den Algocraft nutze bekomme ist zwei Binaries für den Flash (Größe 0x80000) und den EEPROM (Größe 0x8000). Sind im Flash-Bereich irgendwo die Option-Bytes / Security-Settings zu finden? Wenn ja: wo? Die "Volatile Area" besteht wie geschrieben nur aus 0x00 Ich habe ein Bild meiner Verbindungen E1-->MCU angehängt, das habe ich aus der Renesas Application Note entnommen...
Angehängte Dateien:
Zusätzlich macht für mich die laut Renesas vorgeschlagene Verkabelung E1-->MCU für UART keinen Sinn, da hier nur die Tx-Leitung angeschlossen ist. Damit lässt sich weder eine Statusmeldung der MCU empfangen noch etwas auslesen. Alles sehr verwirrend...
Angehängte Dateien:
Konkret für den V850ES/Fx3 noch nicht aber für andere V850/RH850, bisher ohne Probleme. Mit dem E1-Adapter hätte man ja noch die Möglichkeit per "N-Wire" auf den Mikrocontroller zuzugreifen (also per Debugger), das sollte der "Renesas Flash Programmer" nach meiner Erinnerung aber auch unterstützen.
Für den "UART Mode" braucht man die Quarzfrequenz um die Baudrate richtig einzustellen.
Siehe Hardware User Manual Seite 215: "The option bytes are stored as 16-bit data at addresses 0000 007A H and 0000 007B H of the internal code flash memory." Nachtrag: Bezüglich Beschaltung des E1 wäre wohl das "E1/E20 Emulator Additional Document for User’s Manual" für "V850ES und V850E1" das passende, siehe Bild. Der Pullup für RxD könnte eventuell wichtig sein, das hängt von der Schaltung ab.
Angehängte Dateien:
Danke für die Infos! Ich werde gemäß deines Schaltungsausschnittes eine Verdrahtung für UART und dem E1 vornehmen. Echt eigenwillig was Renesas da in seinen Veröffentlichungen in dem von mir zitierten Dokument geschrieben hat - für mich ist das eine klare Fehlinformation. Dein Auszug ist wohl der korrekte. Dass der Takt für die Baudrate wichtig ist, ist klar. Deshalb hat mich ja gewundert, dass er beim Mode CSI auch abgefragt wurde - dort gibt doch SCK den Takt an?! Der Tipp zum Datenblatt war auch hilfreich. Die Option Bytes die der Algocraft ausgelesen hat (0x7a / 0x7b) machen Sinn, die vom BeeProg eher nicht - also hier klare Entscheidung: der Algocraft scheint (!) richtig auszulesen. Bleibt die "Extra Area" in der unter anderem die Security-Bits liegen. Da habe ich keine Ahnung wie ich auf die mit dem Algocraft lesend zugreifen kann. Beim Renesas Flash Programming Tool V2.05 sehe ich auf Anhieb auch keinen Menüpunkt wie ich die anzeigen lassen kann. Nach Datenblatt Seite 305 gibt es nur eine "komplette Readout-Protection". Sollte die gesetzt sein erwarte ich, dass ein Leseversuch entweder mit einer Fehlermeldung quittiert wird oder eben alles 0xff (oder 0x00) ergibt. Liege ich da richtig? Sowie ich irgendwelche Daten lesen kann (egal ob Code oder Datenbereich) ist die Read-Protection nicht gesetzt?
Ist das eventuell für die V850E2M bzw. V850E2S? Zumindest in deren "Additional Document" sieht die Anschlussbelegung so aus wie in dem Diagramm von Dir.
Wenn die "Readout-Protection" gesetzt war hatte ich bisher immer eine Fehlermeldung dass Lesen nicht möglich ist.
Ja, so sollte es sein.
Ich verstehe das so dass der EEPROM mit eingeschlossen ist wenn die "Readout-Protection" gesetzt ist, also entweder alles kann gelesen werden oder nichts. Danke, Du hast mir sehr geholfen. In der Tat hatte ich die Doku für den E2M, nicht die für den E1. Da wird bei CSI offensichtlich nur die Methode mit "HS-Leitung" beim E1-Adapter unterstützt - dann kann das ja auch nicht laufen :) Schade, dass man hier keinen "Daumen hoch" für Beiträge geben kann! Noch eine Idee warum es eventuell beim Kopieren des Flash ein Problem geben könnte: Falls der "Variable Reset Vector" gesetzt ist muss man den beim Kopieren auch berücksichtigen. Der steht in der "Extra Area", ist also in den Flash-Daten die man ausliest nicht enthalten. Der Renesas Flash Programmer sollte das aber könnnen, zumindest stehen die Daten beim Auslesen im Log wie hier im Beispiel:
Die Hochzeit mit dem E1-Programmer war nun erfolgreich (Programming-Mode CSI/H). Ich kann auf alles zugreifen, die Infos zum Chip wie in deinem letzten Posthabe ich angehängt. Der Resetvektor steht also auf Default. Nur die Boot Block Number ist anders... Muss dazu noch was beachtet werden? Vielen Dank nochmal für Deine (und eure) Hilfestellungen! Jede neue MCU hat so ihre Besonderheiten - da reicht alleine Erfahrung oft nicht aus um eine schnelle Lösung zu finden.
Angehängte Dateien:
Der Wert 0xFF für "Boot Block Number" ist eigentlich laut User Manual ein ungültiger Wert (siehe die Tabellen ab Seite 325). In der "Self-Programming Application Note" (über die Self-Programming Library wird u.a. die "Extra Area" verwaltet) steht als Kommentar "The boot cluster size may not be set to 0xFF, which is the default value if not touched before", ich würde daher davon ausgehen dass das nicht verwendet wird und nichts spezielles gemacht werden muss. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
