[PIC] Per Code in den Flash schreiben - Grundlegende Verständnisfragen

[Stefan (Gast)]

Hallo zusammen,

ich habe mal eine Frage zum Schreiben in den internen Flash-Speicher 
eines PICs:

Laut Datenblatt muss ein Flash-Block immer gelöscht werden, bevor in ihn 
hineingeschrieben wird. Warum?
Es scheint zumindest in der Simulation sogar zu Problemen zu führen, 
wenn ich zuvor lösche:

    char buffer[64];
    char k = 0;
    while(k<64)
        buffer[k++] = 2;
    WriteBlockFlash(0x40,1,buffer); // funktioniert, Block enthält überall 0x02
    EraseFlash(0x40,0x7F);          // funktioniert, Block enthält überall 0xFF
    WriteBlockFlash(0x40,1,buffer); // funktioniert nicht, Block enthält überall 0xFF

Ist das ein Bug im Simulator, oder mache ich etwas falsch?

(Etwas seltsam finde ich auch, dass der Funktion EraseFlash die 
Endadresse mitgegeben werden muss, anstelle der Anzahl Blocks, die 
gelöscht werden sollen. Es können doch sowieso nicht einzelne Bytes 
gelöscht werden..)

Viele Grüße
Stefan

[Marc V. (Firma: Vescomp) (logarithmus)]

Stefan schrieb:
> Laut Datenblatt muss ein Flash-Block immer gelöscht werden, bevor in ihn
> hineingeschrieben wird. Warum?

 Weil beim schreiben die bits nur von 1 nach 0 geändert werden können.
 Löschen ist dafür da, um alle bits auf 1 zu setzen.

[Stefan (Gast)]

OK, danke für die Info.
Heißt das dann, dass im Simulator definitiv etwas falsch läuft? Denn der 
erste Schreibvorgang funktioniert in der Simulation (dürfte eigentlich 
nicht funktionieren) und der zweite nach dem Löschen schlägt fehl 
(sollte eigentlich funktionieren).

[Dieter W. (dds5)]

Die Flash-Funktionen stammen ja aus einer Lib und da sollte man 
nachschauen können ob wirklich bis zum Ende des Schreib- bzw. 
Löschvorgangs gewartet wird.

[Stefan (Gast)]

Wo genau kann ich nachsehen? Den Quellcode der Flash-Routinen kann ich 
nicht einsehen. Die PDF zur Peripheral Library sagt dazu auch nichts.

Allerdings glaube ich, dass nach Aufruf der Funktion nicht gewartet 
werden muss. Sieht auch beim Durchsteppen durch den Code nicht so aus, 
da sich ja beim ersten Schreiben und beim Löschen direkt nach aufruf der 
Funktionen der Flash-Inhalt ändert. Nur eben beim zweiten Schreib-Aufruf 
nicht.

[Kastanie (Gast)]

Stefan schrieb:
> Wo genau kann ich nachsehen? Den Quellcode der Flash-Routinen kann ich
> nicht einsehen. Die PDF zur Peripheral Library sagt dazu auch nichts.

Du benutzt doch sicherlich MPLABX?
Klicke bei gedrückter ControlTaste auf die Funktion, dann wird der 
Quelltext der Funktion geöffnet.

Stefan schrieb:
> (Etwas seltsam finde ich auch, dass der Funktion EraseFlash die
> Endadresse mitgegeben werden muss, anstelle der Anzahl Blocks, die
> gelöscht werden sollen. Es können doch sowieso nicht einzelne Bytes
> gelöscht werden..)

Ich habe mit diesen Lib-Funktionen noch nicht gearbeitet aber sieh es 
als Hilfestellung an, dass Du nicht selbst die boundaries errechnen 
musst.
Kann natürlich Probleme machen, wenn nicht zu überschreibende Stellen 
kurz danach kommen und du nicht merkst, dass diese im selben Block wie 
die letzten zu schreibenden Bytes sind. Aber das passiert nur, wenn du 
keinen Überblick über deine Adressaufteilung hast.

Stefan schrieb:
> Ist das ein Bug im Simulator, oder mache ich etwas falsch?
Mag sein, da Hardwarefunktionen nicht immer astrein abzubilden sind.

[Volker S. (vloki)]

Stefan schrieb:
> ich habe mal eine Frage zum Schreiben in den internen Flash-Speicher
> eines PICs

Welcher PIC?
Welcher Compiler?

[Stefan (Gast)]

Kastanie schrieb:
> Du benutzt doch sicherlich MPLABX?
> Klicke bei gedrückter ControlTaste auf die Funktion, dann wird der
> Quelltext der Funktion geöffnet.

Das wusste ich noch gar nicht :-)
Allerdings bekomme ich auch damit nur den function header, nicht den 
kompletten source code. Die Lib wird wohl in compilierter Form vorliegen 
(object file? damit habe ich mich noch nicht befasst)

Kastanie schrieb:
> Kann natürlich Probleme machen, wenn nicht zu überschreibende Stellen
> kurz danach kommen und du nicht merkst, dass diese im selben Block wie
> die letzten zu schreibenden Bytes sind. Aber das passiert nur, wenn du
> keinen Überblick über deine Adressaufteilung hast.

Die Schreibblöcke bilde ich mir schon vorweg selber. Ich weiß also 
genau, welche Daten in welchen Block müssen.

Kastanie schrieb:
> Stefan schrieb:
>> Ist das ein Bug im Simulator, oder mache ich etwas falsch?
> Mag sein, da Hardwarefunktionen nicht immer astrein abzubilden sind.

ok, ich werde einfach weitermachen und am Ende schauen, ob es in 
Realität tut, was es soll.

Volker S. schrieb:
> Welcher PIC?
> Welcher Compiler?

PIC181F25K22 und MplabX mit XC8 Compiler

[Stefan (Gast)]

Zwei Frage habe ich doch noch:

In der Hex-Datei stehen folgende Infos:
 - Programmcode
 - Configuration Bits
 - EEPROM-Daten

1. Könnte noch etwas anderes enthalten sein, was ich aktuell nicht 
bedenke?
2. Schreibe ich die Configuration bits genau wie den Programmcode and 
die angegebene (in diesem Fall 4 Bytes lange) Adresse? Also auch wieder 
vorher Block löschen und dann Block schreiben? Das würde doch bedeuten, 
dass für einen kleinen Moment die Konfiguration in einem ungewünschten 
Zustand ist, was durchaus zu Problemen führen könnte, oder?

[Stefan (Gast)]

Stefan schrieb:
> PIC181F25K22 und MplabX mit XC8 Compiler

Ich meine natürlich PIC18F25K22

[Stefan (Gast)]

So, ich habe es jetzt alles umgesetzt und es funktioniert!
Also Also handelt es sich tatsächlich um einen Bug im Simulator.

Es hat ein wenig länger gedauert, da ich ein Problem mit einer 
berechneten Adresse für den goto Befehl hatte. Dafür mache ich aber ein 
neues Thema auf.

Danke für eure Hilfe!

[Volker S. (vloki)]

Stefan schrieb:
> Allerdings bekomme ich auch damit nur den function header, nicht den
> kompletten source code.

Der Sourcecode liegt im Installationsordner 
microchip/xc8/v1.yx/sources/pic18/plib/Flash