RX65N: flashen von weniger als 128 Byte

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

Markus L. schrieb:

Ich möchte nur einen Block "mehrmals" schreiben

Wozu soll das gut sein???

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.