Hallo, ich versuche z.Zt. einen Bootloader für den Controller RX65N zu schreiben (portieren). Hierbei gibt es Protokollbedingt (*) das Problem, dass Bereiche geschrieben werden müssen, die kleiner als 128 Byte sind (der Controller erlaubt nur Flashen in 128 Byte grossen Blöcken). Ich versuche das Problem zu umgehen, indem ich die "fehlenden" Bytes mit 0xff auffülle. Leider können die aufgefüllten Bytes dann auch nicht mehr im nachhinein geflashed werden. Erst nachdem der Block gelöscht wurde, ist wieder ein schreiben möglich. (*): das Protokoll ist vorgegeben (Segger HexLoad). Die zu flashenden Daten kommen in Paketen, jedes Paket muss sofort geflashed werden (damit Erfolg/Misserfolg) zurückgesendet werden kann. Die "Nutzdaten" in dem Paket starten nicht immer auf einer 128 Byte Addresse. Bevor ich jetzt anfange, das Protokoll auseinander zu nehmen: Hat jemand eine Idee, wie ich aus der Nummer rauskomme? Vlt. gibt es irgendwo ein Register, dass ich zurücksetzen muss, nachdem ich die 0xff's geschrieben habe? Vielen Dank, Markus
Was erwartest du? Ich finde es schon erstaunlich das die Blockgroesse nur 128Byte ist. Ich haette eher was im kB Bereich erwartet. Das ist einfach der Flashtechnologie geschuldet. VAnye
Vanye R. schrieb: > Was erwartest du? Ich schreibe immer Blockweise. Ich möchte nur einen Block "mehrmals" schreiben, aber dabei ändern sich nur die Bytes, die zuvor noch nicht geschrieben wurden und noch 0xff sind. Markus
Typisch sammelt man die Daten erstmal im RAM. Ist eine 128 Byte Page komplett, wird diese geschrieben. Derweil können schon weitere Pakete empfangen werden. Damit umgeht man auch das Problem, daß Pakete nicht 128Byte aligned sind. Sie müssen nur aufsteigend sortiert sein. Markus L. schrieb: > jedes Paket muss sofort geflashed werden (damit > Erfolg/Misserfolg) zurückgesendet werden kann. Warum? Ein Flashbefehl gibt nicht zurück, ob die Daten auch wirklich geschrieben wurden. Eine Dummyantwort reicht daher völlig aus, damit das Senden fortgesetzt wird. Einen Mißerfolg kann man nur durch ein nachfolgendes Verify aller Daten erkennen. In meinem Bootloader hatte ich einen Befehl implementiert, der die maximale Puffergröße sendet. Der Programmer konnte dann bis zu diesem Wert Bytes full speed rausrotzen und wartete erst danach auf das Zeichen zum Fortsetzen.
Max M. schrieb: > Wozu soll das gut sein Das habe ich oben versucht zu erklären: Das (vorgegebene) Protokoll versendet Datenpakete die sofort geflashed werden müssen (Rückmeldung an den PC, ggf. Wiederholung im Fehlerfall). Diese PAkete sind (aktuell) nicht 128 Byte gross, so das sich Überschneidungen ergeben. Beispiel: Paket1 beinhaltet die ersten 20 Bytes. Um diese 20 Bytes flashen zu können, müssen die "fehlenden" Bytes mit 0xff aufgefüllt werden. Paket2 beinhaltet dann die Bytes ab 21. Jetzt müssen die zuvor mit 0xff aufgefüllten bytes erneut (jetzt mit den korrekten Werten) geschrieben werden, die Bytes bis 20 müssen aber erhalten bleiben. Die einzige Möglichkeit, die ich im Moment sehe, ist das Ändern der Pakete auf 128 Byte, was aber eine Änderung auf PC-Seite erfordert. Es erschliesst sich mir nicht, warum Bytes mit 0xff nicht "erneut" geflashed werden können. Markus
Peter D. schrieb: > Sie müssen nur aufsteigend sortiert sein Das ist katuell nicht sichergestellt. > Einen Mißerfolg kann man nur durch ein nachfolgendes Verify aller Daten erkennen Aktuell wird jedes geschriebene Paket sofort zurückgelesen und bei Misserfolg das Paket nochmals gesendet. Markus
Eine Suchmaschine hilft ("RX651 cannot self program the same 128 byte
page twice without erasing":
https://community.renesas.com/mcu-mpu/rx/f/rx-forum/14903/rx651-cannot-self-program-the-same-128-byte-page-twice-without-erasing
Der relevante Teil:
1 | It is stated on page 2599 in the datasheet for the RX65* |
2 | |
3 | (3) Prohibition of Additional Programming |
4 | Programming a given area of the code flash memory or data flash memory twice is not possible. To program the code flash memory or data flash memory where has been programed, erase the target area. Programming can be added to the option-setting memory. For details, refer to Flash Memory User’s Manual: Hardware Interface. |
Dieter S. schrieb: > Eine Suchmaschine hilft ("RX651 cannot self program the same 128 byte > page twice without erasing": Danke. Das hatte ich noch nicht gefunden. Markus
Ok, so sollte es klappen: vor dem schreiben eines Blockes, den aktuellen Flashinhalt auf bytes != 0xff untersuchen. Wenn welche da sind, den Block ins RAM lesen, die neuen Bytes in den Block im RAM übernehmen, Block im Flash löschen und dann komplett neu flashen. Markus
Markus L. schrieb: > Wenn welche da sind, den Block ins RAM lesen, die neuen Bytes in den > Block im RAM übernehmen, Block im Flash löschen und dann komplett neu > flashen. Ein Block kann bis zu 32kB groß sein, das wird also seine Zeit brauchen. Einfacher dürfte sein, das PC Programm sendet die Daten immer aligned und aufsteigend.
Stimmt. Du hast Recht. Dann würde jeder Block zig mal gelöscht. Also doch die PC-Software anpassen... MArkus
Markus L. schrieb: > Ok, so sollte es klappen: > > vor dem schreiben eines Blockes, den aktuellen Flashinhalt auf bytes != > 0xff untersuchen. > Wenn welche da sind, den Block ins RAM lesen, die neuen Bytes in den > Block im RAM übernehmen, Block im Flash löschen und dann komplett neu > flashen. > > Markus Wozu untersuchen? Wenn Du das unbedingt so willst, dann liest du stumpf immer den ganzen Block ein, ersetzt im Block den Teil mit den neuen Daten aus dem Paket und schreibst den ganzen Block neu runter. (Nach vorherigem Löschen) Machen würde ich das aber nicht. Was die Hersteller mit Schreib/Erase Zyklen eigentlich meinen sind Löschzyklen. D.h. jeder Löschvorgang ist ein kompletter Zyklus für den ganzen Sektor. Bei solchen Häppchenweisen Zugriffen ist der Flash schneller kaputt als man denkt. Das Problem an der Sache ist, das Ganze äußert sich nicht sofort, sondern erst nach einer gewissen Betriebszeit. Denn was da im Flash eigentlich passiert ist, das die Data-Retention mit jedem Löschzyklus ein klein wenig abnimmt. Eine Flashpage Byte-Weise nach dem Löschen zu schreiben will man auch nicht. Viele moderne Flash können das nämlich nicht wirklich, auch wenn es am Anfang so aussieht als ob es funktioniert. Da können die merkwürdigsten Effekte auftreten, z.B. das Bits in völlig anderen Pages kippen. Merke: alles was der Flash-Hersteller nicht explizit in seinem Datenblatt erlaubt, sollte man nicht tun. Normalerweise muss den Sektor komplett löschen, danach darf man jede Page in dem Sektor separat, aber einmalig beschreiben. Wenn da die Daten wirklich nur in so kleinen Häppchen kommen taugt die Software vielleicht nicht für Euren Anwendungsfall. Aber ehrlich gesagt habe ich sowas noch nie gehört. (Wir flashen hier in 4kB Sektoren)
Markus L. schrieb: > (*): das Protokoll ist vorgegeben (Segger HexLoad). Klingt nach emLoad: https://www.segger.com/products/field-upgrades/emload/ Sollte es da nicht schon von uns die fertige Software für den RX65N geben? Gerne bei uns melden oder ich frage auch gerne mal ein Büro weiter nach ;-).
Markus L. schrieb: > (*): das Protokoll ist vorgegeben (Segger HexLoad). Die zu flashenden > Daten kommen in Paketen, jedes Paket muss sofort geflashed werden (damit > Erfolg/Misserfolg) zurückgesendet werden kann. Die "Nutzdaten" in dem > Paket starten nicht immer auf einer 128 Byte Addresse. Liegen die zu flashenden Daten in einem bekannten Format vor, z.B. Intel Hex? Dann könnte man diese Datei manipulieren, so dass a) die Pakete in aufsteigender Reihenfolge kommen und b) diese immer 128 Byte groß sind. Z.B. alle Pakete in einem Zwischenspeicher einlesen, der vorher auf $FF gesetzt wurde, sich die kleinste und größte Adresse merken und dann schön eine neue Hex Datei ausgeben mit aufsteigenden 128 Byte Paketen, auf Sektorgrenzen aligned.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.