Hallo zusammen,
ich habe hier ein FRAM von Cypress Typ FM25V20 im pg format.
Dieser FRAM kommuniziert über SPI. Mehrere versuche diesen FRAM
auszulesen scheiterten leider alle.
Ich probiere es aktuell mit einem Raspberry Pi 3b+ und dem tool
Flashrom.
This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE
319
The test status of this chip may have been updated in the latest development
320
version of flashrom. If you are running the latest development version,
321
please email a report to flashrom@flashrom.org if any of the above operations
322
work correctly for you with this flash chip. Please include the flashrom log
323
file for all operations you tested (see the man page for details), and mention
324
which mainboard or programmer you tested in the subject line.
325
Thanks for your help!
326
Read is not working on this chip. Continuing anyway.
327
flashrom has no read function for this flash chip.
328
Aborting.
Wahrscheinlich ist dieser Typ von Flashrom einfach nicht unterstützt,
ich hatte nur die Hoffnung, dasss es als "Genereic unknown"
funktionieren könnte.
Ich brauche ein bisschen Input was ich noch probieren könnte. Zur
Verfügung steht ein Raspberry mit Breadboard, ein ATMEL Evaluation Board
2.0.1 und der mysmartusb light Programmer. Windows 10 und Linux.
Bin gespannt auf eure Ideen:)
Nobody schrieb:> ich habe hier ein FRAM von Cypress Typ FM25V20 im pg format.Nobody schrieb:> Dieser FRAM kommuniziert über SPI.
Was ist ein pg format?
Nein, ein FRAM kommuniziert nicht, sondern allerhöchstens
ein Programmer oder in deinem Fall ein Raspberry.
Ein FRAM reagiert nur auf SPI Kommandos, kommuniziert also nicht.
Allein deine Ausdrucksweise signalisiert dass du nicht recht
weisst was du tust.
Nobody schrieb:> Bin gespannt auf eure Ideen:)
Ich habe ein grossartige: Zeige deinen Schaltplan sowie den
Aufbau deiner Testanordnung.
Erst dann wird man dir sagen können ob und was du falsch machst.
Nobody schrieb:
> ich habe hier ein FRAM von Cypress Typ FM25V20 im pg format.
Nobody schrieb:
> Dieser FRAM kommuniziert über SPI.
Was ist ein pg format?
>> darf ich hier verlinken? sonst einfach nach FM25V20-pg suchen. Also ein DIP
Gehäuse.
Nein, ein FRAM kommuniziert nicht, sondern allerhöchstens
ein Programmer oder in deinem Fall ein Raspberry.
Ein FRAM reagiert nur auf SPI Kommandos, kommuniziert also nicht.
>> Ich habe mich eher auf das Problem an sich konzentriert und weniger auf die
Ausdrucksweise ob hier kommuniziert oder "befohlen" und "ausgeführt" wird. Aber ja
du hast recht.
Allein deine Ausdrucksweise signalisiert dass du nicht recht
weisst was du tust.
>> Lasse ich jetzt mal so stehen
Nobody schrieb:
> Bin gespannt auf eure Ideen:)
Ich habe ein grossartige: Zeige deinen Schaltplan sowie den
Aufbau deiner Testanordnung.
>> Ich habe mal drei Fotos angehängt. Ich wollte mit den Leitungen möglichst nah
an die Pins deswegen ist es etwas unübersichtlich.
Raspberry------------------------FRAM
PIN 17 +3,3V---------------------PIN 8 VDD
PIN 19 MOSI----------------------PIN 5 SI
PIN 21 MISO----------------------PIN 2 SO
PIN 23 SCLK----------------------PIN 6 SCK
PIN 25 GND-----------------------PIN 4 VSS
PIN 24 CE0-----------------------PIN 1 CS
---------------------------------PIN 3 WP->PIN 8 VDD
---------------------------------PIN 7 HOLD-> PIN 8 VDD
Ich glaube das ganze funktioniert nicht richtig, da im Datasheet davon
die rede ist, dass das Lesekommando erst nach der fallenden Flanke von
CS beginnt und Flashrom das vielleicht nicht tut.
Oder sehe ich da was falsch?
Bitte lerne korrekt zu zitieren. Was Du da gerade abgeliefert hast, ist
vornehm umschrieben "wirr".
Vor Deine Antworten auf zitierte Fragen gehört keine einzige
Spitzklammer.
Softwareseitig ist ein SPI-FRAM wie ein SPI-Flash zu behandeln, da
gibt's (außer dass das Programmieren ein "wenig" schneller geht und ein
vorheriges Löschen entbehrlich ist) kaum einen Unterschied.
Da die ID dem flashrom allerdings unbekannt ist, weiß das gute Stück ja
nicht einmal über die Kapazität Bescheid - und nicht, ob z. B. 3- oder
4-Byte-Adressierung nötig ist ...
Es bleibt also nur, in Erfahrung zu bringen, ob bzw. wie man beim
flashrom die ganzen Parameter des Chips manuell vorgeben kann. Wenn das
nicht geht, müsste man halt den Sourcecode vom flashrom etwas patchen.
Eine neue ID mit den Parametern in die vorhandenen Tabellen einbauen
dürfte simpel sein --- wäre da nicht das Problem mit der ID-Länge. Die
meisten Programmierer lesen wohl nur die ersten 3 Bytes aus, hier sind
dummerweise 9 für die eindeutige Identifizierung nötig. Eine
Quick&Dirty-Lösung wäre, als ID einfach 0x7F, 0x7F, 0x7F einzutragen.
Die ID (oder vielmehr ihr Anfang) sieht ja schon man richtig aus, nur
sind diese "continuation codes" etwas lästig, aber ansonsten sieht es
hardwaremäßig völlig in Ordnung aus.
Falls es auf ein eigenes Programm hinaus läuft, für den FM25V10 hat
schon jemand etwas veröffentlicht. Ist zwar für einen AD µC, das
betrifft aber nur die Test asm Befehle. C sollte passen.
Da es der FM25V20 ist, muss evtl die ID irgendwo angepasst werden.
Muss aber nicht sein, wenn die nicht benutzt wird.
https://github.com/pkrich/FM25V10
pegel schrieb:> Falls es auf ein eigenes Programm hinaus läuft, für den FM25V10 hat> schon jemand etwas veröffentlicht. Ist zwar für einen AD µC, das> betrifft aber nur die Test asm Befehle. C sollte passen.
Wow, ein extra Programm für so'ne kümmerliche Ausleseaktion? Ist das
nicht ein bisserl übertrieben? Wie schon gesagt, SPI-FRAM ist wie
SPI-Flash ...
A. B. schrieb:> pegel schrieb:>> Falls es auf ein eigenes Programm hinaus läuft, für den FM25V10 hat>> schon jemand etwas veröffentlicht. Ist zwar für einen AD µC, das>> betrifft aber nur die Test asm Befehle. C sollte passen.>> Wow, ein extra Programm für so'ne kümmerliche Ausleseaktion? Ist das> nicht ein bisserl übertrieben? Wie schon gesagt, SPI-FRAM ist wie> SPI-Flash ...
Ich glaube da brauche ich noch etwas mehr Hilfe.
Ich habe leider keinerlei Programmierkenntnisse. Ich habe mich jetzt mal
durch ein paar flashrom wikis durchgelesen.
Ich habe folgendes in meine flashchips.c ergänzt:
1
{
2
.vendor = "Cypress",
3
.name = "FM25V20",
4
.bustype = BUS_SPI,
5
.model_id = CYPRESS_FM25V20,
6
.total_size = 256,
7
.page_size = 256,
8
.tested = TEST_OK_PR,
9
.probe = probe_jedec,
10
.probe_timing = TIMING_ZERO,
11
.write = write_jedec_1,
12
.read = read_memmapped,
13
.voltage = {2000, 3700},
14
},
und folgendes in flashchips.h:
1
#define CYPRESS_ID 0x7F
2
#define CYPRESS_FM25V20 0x7F, 0x7F, 0x7F
das war aber eher alles vergleichen/testen/probieren da ich davon leider
keinerlei Ahnung habe.
Da sind wahrscheinlich Fehler drin.
Das Kompilieren funktioniert nur beim testen kriege ich jetzt
"Bus-Zugriffsfehler".
@Helmut: Was für einen Kondensator empfiehlst du hier?
Danke schonmal für die Antworten
Nobody schrieb:> Ich habe folgendes in meine flashchips.c ergänzt:>>
1
> {
2
> .vendor = "Cypress",
3
> .name = "FM25V20",
4
> .bustype = BUS_SPI,
5
> .model_id = CYPRESS_FM25V20,
6
> .total_size = 256,
7
> .page_size = 256,
8
> .tested = TEST_OK_PR,
9
> .probe = probe_jedec,
10
> .probe_timing = TIMING_ZERO,
11
> .write = write_jedec_1,
12
> .read = read_memmapped,
13
> .voltage = {2000, 3700},
14
> },
15
>
Warum so kompliziert? Einfach einen SPI-Flash mit gleicher Kapazität
suchen, die entsprechende Manufacturer ID auf 0x7F ändern,
die Chip-ID auf 0x7F7F (oder der Eintrag kopieren und ensprechend
ändern, dann sollte "name" natürlich auch geändert werden), und das
war's.
> und folgendes in flashchips.h:>>
1
> #define CYPRESS_FM25V20 0x7F, 0x7F, 0x7F
2
>
Das geht nicht, denn die 3-Byte-ID wird innerhalb flashrom in zwei Teile
zerlegt, erstes Byte die Manufacturer-ID, und die restlichen beiden
Bytes zusammen sind die Chip-ID, also "0x7F7F", nicht "0x7f, 0x7F,
0x7F". Nicht umsonst sieht man in der Ausgabe jeweils "id1 0x7f7f, id2
0x7f".
"name" anzupassen, ist nur Kosmetik und für eine einmalige Aktion
überflüssig.
A. B. schrieb:> Warum so kompliziert? Einfach einen SPI-Flash mit gleicher Kapazität> suchen, die entsprechende Manufacturer ID auf 0x7F ändern,> die Chip-ID auf 0x7F7F (oder der Eintrag kopieren und ensprechend> ändern, dann sollte "name" natürlich auch geändert werden), und das> war's.>>> und folgendes in flashchips.h:>>>>> #define CYPRESS_FM25V20 0x7F, 0x7F, 0x7F>>> Das geht nicht, denn die 3-Byte-ID wird innerhalb flashrom in zwei Teile> zerlegt, erstes Byte die Manufacturer-ID, und die restlichen beiden> Bytes zusammen sind die Chip-ID, also "0x7F7F", nicht "0x7f, 0x7F,> 0x7F". Nicht umsonst sieht man in der Ausgabe jeweils "id1 0x7f7f, id2> 0x7f".> "name" anzupassen, ist nur Kosmetik und für eine einmalige Aktion> überflüssig.
So kompliziert wars jetzt gar nicht. Ich habe flashchips.c jetz so
angepasst.
1
{
2
.vendor = "Cypress",
3
.name = "FM25V20",
4
.bustype = BUS_SPI,
5
.manufacture_id = CYPRESS_ID,
6
.model_id = CYPRESS_FM25V20,
7
.total_size = 256,
8
.page_size = 256,
9
.tested = TEST_UNTESTED,
10
.probe = probe_spi_rdid,
11
.probe_timing = TIMING_ZERO,
12
.write = write_jedec_1,
13
.read = read_memmapped,
14
.voltage = {2000, 3700},
15
},
und flashchips.h
1
#define CYPRESS_ID 0x7F7F
2
#define CYPRESS_FM25V20 0x7F
so findet er jetzt auch den FRAM.
1
...
2
Probing for ST unknown ST SPI chip, 0 kB: probe_spi_rdid_generic: id1 0x7f7f, id2 0x7f
Das auslesen läuft durch nur erhalte ich jetzt eine leere datei:
1
pi@test:~/git/flashrom $ hexdump test.bin
2
0000000 0000 0000 0000 0000 0000 0000 0000 0000
3
*
4
0040000
Auch wenn das jetzt komplizierter war als du vorgeschlagen hast ist das
so korrekt? Er findet ja den richtigen typen. jetzt ist nur die frage,
warum ich eine leere Datei bekomme. Im FRAM sollten Daten gespeichert
sein. Zudem kommt mir die Datei etwas klein vor oder ist das richtig so?
lauten, analog beim .write. Deshalb hatte ich gerade vorgeschlagen, einen Eintrag von einem entsprechenden SPI-Flash zu nehmen ;-)
20
21
> .voltage = {2000, 3700},
22
> },
23
>
>> und flashchips.h>
1
> #define CYPRESS_ID 0x7F7F
2
> #define CYPRESS_FM25V20 0x7F
3
>
> so findet er jetzt auch den FRAM.
Das sollte eigentlich genau anders herum sein: Manufacturer ist ein(!)
Byte und die eigentliche Chip-ID zwei(!) Bytes.
> Das auslesen läuft durch nur erhalte ich jetzt eine leere datei:>
1
> pi@test:~/git/flashrom $ hexdump test.bin
2
> 0000000 0000 0000 0000 0000 0000 0000 0000 0000
3
> *
4
> 0040000
5
>
> Auch wenn das jetzt komplizierter war als du vorgeschlagen hast ist das> so korrekt? Er findet ja den richtigen typen. jetzt ist nur die frage,> warum ich eine leere Datei bekomme. Im FRAM sollten Daten gespeichert> sein. Zudem kommt mir die Datei etwas klein vor oder ist das richtig so?
Die Länge der Datei ist doch 0x40000 (auch wenn nur ein Teil ausgegeben
wird, '*' steht für "usw."), das sind 256 kByte, das passt doch.
A. B. schrieb:> Nobody schrieb:>>> {>> .vendor = "Cypress",>> .name = "FM25V20",>> .bustype = BUS_SPI,>> .manufacture_id = CYPRESS_ID,>> .model_id = CYPRESS_FM25V20,>> .total_size = 256,>> .page_size = 256,>> .tested = TEST_UNTESTED,>> .probe = probe_spi_rdid,>> .probe_timing = TIMING_ZERO,>> .write = write_jedec_1,>> .read = read_memmapped,>> Das müsste aber>> .read = spi_chip_read,>> lauten, analog beim .write. Deshalb hatte ich gerade vorgeschlagen,> einen Eintrag von einem entsprechenden SPI-Flash zu nehmen ;-)>>> .voltage = {2000, 3700},>> },>> >>> und flashchips.h>>> #define CYPRESS_ID 0x7F7F>> #define CYPRESS_FM25V20 0x7F>> > so findet er jetzt auch den FRAM.>> Das sollte eigentlich genau anders herum sein: Manufacturer ist ein(!)> Byte und die eigentliche Chip-ID zwei(!) Bytes.>>> Das auslesen läuft durch nur erhalte ich jetzt eine leere datei:>>> pi@test:~/git/flashrom $ hexdump test.bin>> 0000000 0000 0000 0000 0000 0000 0000 0000 0000>> *>> 0040000>>>> Auch wenn das jetzt komplizierter war als du vorgeschlagen hast ist das>> so korrekt? Er findet ja den richtigen typen. jetzt ist nur die frage,>> warum ich eine leere Datei bekomme. Im FRAM sollten Daten gespeichert>> sein. Zudem kommt mir die Datei etwas klein vor oder ist das richtig so?>> Die Länge der Datei ist doch 0x40000 (auch wenn nur ein Teil ausgegeben> wird, '*' steht für "usw."), das sind 256 kByte, das passt doch.
Okay das read und write habe ich angepasst. Write gab es zweimal,
spi_chip_write1 und spi_write_chip256.
Ich habe write1 probiert.
1
{
2
.vendor = "Cypress",
3
.name = "FM25V20",
4
.bustype = BUS_SPI,
5
.manufacture_id = CYPRESS_ID,
6
.model_id = CYPRESS_FM25V20,
7
.total_size = 256,
8
.page_size = 256,
9
.tested = TEST_UNTESTED,
10
.probe = probe_spi_rdid,
11
.probe_timing = TIMING_ZERO,
12
.write = spi_chip_write_1,
13
.read = spi_chip_read,
14
.voltage = {2000, 3700},
15
},
Im Header hab ich es nochmal versucht mit CYPRESS_ID 0x75 und
CYPRESS_FM25V20 0x7F7F. Dann erkennt er aber den Chip nicht mehr und
sagt gerenic unknown flash chip.
Angenommen der Flash ist wirklich leer und der Output wäre korrekt würde
ich gerne noch die gegenprobe machen und daten auf den Chip schreiben.
Ich habe mir mit dd eine Datei erzeugt und versucht diese zu schreiben
jedoch möchte flashrom unbedingt vorher löschen obwohl ich auch den
eraseblock teil raus genommen habe.
https://www.flashrom.org/Easy_projects#Add_.28ferroelectric.2C_F-RAM.29_SPI_chips_made_by_Cypress_.2F_Ramtron
Hier steht auch, dass bei Cypress Chips ein löschen nicht notwendig ist.
Ich weiß leider nicht wo ich das noch deaktivieren muss damit flashrom
die daten schreibt ohne zu löschen.
Kannst du mir da auch helfen?
Lg
Löschen einfach ignorieren: Das FRAM kennt das entsprechende Kommando
nicht und sollte daher nach dessen Empfang gar nichts tun. Ärgerlich
wär's nur, wenn flashrom nach dem Löschen automatisch prüft, ob überall
0xFF drinsteht, aber das macht es wahrscheinlich nicht.
Zu Frage leer oder nicht leer: Wo kommt das FRAM her? Frisch oder
irgendwo ausgebaut? Im ersten Fall wär's nicht verwunderlich. Leider
weiß ich nicht mehr, wie der Ursprungszustand bei den FRAMs ist, hatte
schon verschiedene ausprobiert, auch von Fujitsu. Im Datenblatt habe ich
dazu auf die Schnelle keinen Kommentar gesehen, müsste man noch mal
gründlich durchlesen ...
Thread beobachten
Seitenaufteilung abschalten