AT45DB161D 528byte page size

[Olliver (Gast)]

hallo, hab da mal ein kleines Problem.

Seit geraumer Zeit beschäftidge ich mich mit dem AT45Db161D, hab da 
einen treiber zum löschen und schreiben geschrieben, also über usb 
werden daten an das Flash geschickt...Nun hab als erstes mit der Page 
size 512 bytes gearbeitet und hab soweit alles hinbekommen kann lesen, 
löschen und schreiben. Nun dann sollte ich doch das mit der Page size 
528 bytes durchführen, da die 512 nicht wieder rückgängig gemachtr 
werden können. Soweit so gut. eigentlich sollte normalerweise ja nur die 
Address bytes nach dem opcode auf ein bit erhöht werden, habs auch dann 
laut datenblatt so getan, aber leider kann ich das Flash nicht richtig 
schreiben. Es werden zwar richtige Daten geschrieben aber nur zum Teil. 
zwischen den richtigen Daten haben sich lauter nullen eingeschlichen. 
Woran kann das denn liegen. Auf dem Oszi betrachtet sehe ich die 
richtigen Daten ins Flash gehen und die Page Addresse wird auch richtig 
hochgezählt. Nur wenn ich jetzzt das Flash mit Impact auslese, sind da 
zu viele daten drin zwar auch die richtigen aber auch einfach nullen. 
Woran kann das denn liegen. Muss ich da nochwas anderes an mein Code 
verändern. Zu beginn zu ich ja den Prog_B Pin des FPGA auf low setzen 
und wenn ich nach dem schreiben wieder high setze wird er auch gesetzt, 
aber da falsche Daten im Flash sind, kann das FPGA n icht richtig 
konfiguriert werden, somit bleibt dann der DONE Pin des FPGA auf Low.

Hoffe da kann einer mir weiterhelfen.

so sieht der Code aus: Main Memory Through Buffer

addressfield[0] = (unsigned char) (page >> 6) & 0x3F;//7-----512bytes:  >>7
  addressfield[1] = (unsigned char) ((page << 2) & 0xFC) | (unsigned char) ((byte >> 8) & 0x3); //-----512bytes: <<1
  addressfield[2] = (unsigned char) (byte & 0xFF);

  GPIOPinWrite( GPIO_PORTA_BASE, GPIO_PIN_3, 0);            //CS Low

     //Main Memory page program through Buffer
     SSIDataPut(SSI0_BASE, 0x82);
     SSIDataGet(SSI0_BASE, &dummy);

     for(i=0; i<3; i++){

       SSIDataPut(SSI0_BASE, addressfield[i]);
       SSIDataGet(SSI0_BASE, &dummy);

     }

     //send Data
     for(ulindex = 0; ulindex < Len; ulindex++)
       {
        SSIDataPut(SSI0_BASE, Data[ulindex]);
        SSIDataGet(SSI0_BASE, &dummy);
       }

     GPIOPinWrite( GPIO_PORTA_BASE, GPIO_PIN_3, GPIO_PIN_3); //CS High

page = Pageaddresse
byte = Byteaddresse (ist ja immer null, da es immer von von Anfang 
schreiben soll)

laut Datenblatt:

To perform a main memory
page program through buffer for the standard DataFlash page size (528 
bytes), a 1-byte opcode,
82H for buffer 1 or 85H for buffer 2, must first be clocked into the 
device, followed by three
address bytes. The address bytes are comprised of 2 don’t care bits, 12 
page address bits,
(PA11 - PA0) that select the page in the main memory where data is to be 
written, and 10 buffer
address bits (BFA9 - BFA0) that select the first byte in the buffer to 
be written

[Olliver (Gast)]

keiner ne idee????

[Olliver (Gast)]

Mir ist aufgefallen, wenn ich das Flash auslese und die Daten mit den 
original Daten vergeliche, dann stelle ist fest, dass zu beginn jeder 
Page, die ersten 16 bytes irgendweclhe komische bytes sind, die aber zu 
beginn jeder Page auftreten immer dieselben bytes. Woran kann das denn 
jetzt liegen, ich schicke doch die richtigen Daten in der richtigen 
reihenfolge, wenn ich nun zurücklese ist sind da auch andere bytes 
dabei.

[Sascha W. (sascha-w)]

Hallo,

ich gehe davon aus, das du für den Test mit 528Byte einen neuen Chip 
genommen hast.
Wie beschreibst/liest du den Chip? Immer nur Page-Weise, so das byte=0?

Sascha

[Olliver (Gast)]

ja hab einen neuen chip genommen. ja also die pageaddressen werden 
hochgezählt, also page und byte =0; da die Addresse am Anfang ja null 
ist.

Nochwas, es ist nicht zu beginn jeder Page sondern nach dem Ende von 512 
übertragenen bytes, ist im flash eine Sequenz von 16 bytes, die keine 
Ahnung woher kommt, also beim Senden ist die nicht dabei, aber sobald 
ich den Prog_B Pin auf high setze um das übertragen zu quittieren, dann 
läuft immer was schief, auf dem oszi sehe ich dann, wie das CLk des 
Flash verrauscht ist, sowie di anderen Leitungen.....

[Sascha W. (sascha-w)]

Olliver schrieb:
> ja hab einen neuen chip genommen. ja also die pageaddressen werden
> hochgezählt, also page und byte =0; da die Addresse am Anfang ja null
> ist.
also du schreibst die ersten 528Byte mit Page=0; Byte=0, die zweiten 
528Byte mit Page=1; Byte=0; usw. ?
Wenn man die Bits von Page und Byte hintereinander stellt, ergibt sich 
ja keine durchgehende Adresse so wie bei Verwendung von 512Byte-Pages.

> Nochwas, es ist nicht zu beginn jeder Page sondern nach dem Ende von 512
> übertragenen bytes, ist im flash eine Sequenz von 16 bytes, die keine
> Ahnung woher kommt, also beim Senden ist die nicht dabei,
wenn die 16Bytes nicht beschrieben würden, dann sollte der Wert immer 
0xFF sein

> aber sobald
> ich den Prog_B Pin auf high setze um das übertragen zu quittieren, dann
> läuft immer was schief, auf dem oszi sehe ich dann, wie das CLk des
> Flash verrauscht ist, sowie di anderen Leitungen.....
warum sollte das schief laufen? das wird der Erase-Write-Zyklus sein - 
der sollte auch bei 512Byte-Pages zu sehen sein. Abblockkondensatoren 
dran?

Sascha

[Olliver (Gast)]

Also hier hätte ich jetzt doch eine Frage, vorher hatte ich die 512 byte 
page size ja genommen weil ich 512 byts Daten sende, wie ist das jtzt 
mit den 528 byte page size, da sende ich ja nur 512 Datenbytes, was ist 
dann mit den restliche freien Bytes, ahh jetzt verstehe ich, ich sende 
ja nur 512 bytes und in den 16 bytes schreibt er irgendetwas rein, oohh.

Wie mache ich das jetzt, soll ich etwa immer 16 bytes des nächtes 512 
Datenbyte streams in das vorige reinschreiben, oder wie jetzt.

"Wenn man die Bits von Page und Byte hintereinander stellt, ergibt sich
ja keine durchgehende Adresse so wie bei Verwendung von 512Byte-Pages."

Warum denn das, ich stelle ja eine 24 bit Addresse aus den page- und 
Byte bits zusammen. Also 528byte können ja die datenbytes sein, nach dem 
OPcode wird doch eine 24 bit Addresse bestehend aus Page und Buffer bits 
zusammengestellt, laut Datenblatt, dass tu ich ja auch, der einzige 
Unterschied von 528 und 512 bytes ist ja ein bit.

[Olliver (Gast)]

So hab das Problem gelöst nun läuft alles. Hab die DLL geändert, da ich 
ja eine DFU programmiert habe, nun sende ich darüber an den uc 528 bytes 
das wars, ich habe vor lauter Bäumen den Wald nicht gesehen.

Danke für euere Hilfe und Geduld.

[Sascha W. (sascha-w)]

Olliver schrieb:
> "Wenn man die Bits von Page und Byte hintereinander stellt, ergibt sich
> ja keine durchgehende Adresse so wie bei Verwendung von 512Byte-Pages."
>
> Warum denn das, ich stelle ja eine 24 bit Addresse aus den page- und
> Byte bits zusammen. Also 528byte können ja die datenbytes sein, nach dem
> OPcode wird doch eine 24 bit Addresse bestehend aus Page und Buffer bits
> zusammengestellt, laut Datenblatt, dass tu ich ja auch, der einzige
> Unterschied von 528 und 512 bytes ist ja ein bit.
ja +1Bit - das würde rein binär ja eine Verdoppelung des Speicherplatzes 
darstellen.
In jeder Page gibts 1024 Byteadressen, von denen aber nur 528 als 
Speicher zur Verfügung stehen (Byte 0...527); Adresse 528...1023 ist 
nicht benutzbar.
Das 529'zigste Byte liegt, innerhalb der 24bit-Speicheradresse des 
Chips, schon bei Adresse 1024.

Sascha