mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Problem mit dem Flash


Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Abend,
vielleicht kann mit jemand helfen.
Ich sitze gerade an diesem Flash
http://www.farnell.com/datasheets/1756776.pdf
und versuche diesen in Betrieb zu nehmen.
Der Aufbau ist recht simpel, uC, Flash und UART zum PC.
Auf der Seite 63 des Datenblattes steht das Beschreiben beschrieben.
Ich mache das so:
1. SS auf LOW
2. SPI_TxData(0x02); // Writecomand

3. SPI_TxData(0x7F);   // Adress 0x7FF000
SPI_TxData(0xF0);   // Adress
SPI_TxData(0x00);   // Adress

4. SPI_TxData(0x33);   // Data to write
5. SS auf High

Auf dem Oszi sieht das gut aus. Weiß aber nicht, ob die Daten wirklich 
geschrieben sind.

Danach wollte ich die auslesen.
1. SS auf LOW
2. SPI_TxData(0x03); // Readcomand

3. SPI_TxData(0x7F);   // Adress 0x7FF000
SPI_TxData(0xF0);   // Adress
SPI_TxData(0x00);   // Adress

4. SPI_TxData(0x00);   // Dummy für Clock
5. Flashdata = SPI_RX();   // Hier sollten die empfangene Daten der 
Variable übergeben werden.
6. SS auf High
7. Falshdata per UART ausgeben

Leider ist die über UART ausgegebene Variable 0x00, wie anfangs 
initialisiert.
Oszi sagt, dass auch am MISO Pin des uC nichts los ist.

Das Problem werden eher nicht die SPI Befehle (SPI_TxData) sein, da ich 
mit SPI schon früher gearbeitet habe.

Kann jemand bitte das Datenblatt überfliegen, ob ich etwas übersehen 
habe?
Bin selbst ein relativer Neuling und wurde von umfangreichem Datenblatt 
komplett erschlagen.

Ich danke vielmals.
Beste Grüße JT

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso, noch vergessen:
Write enable ist ganz zu Anfang gesetzt mit
1. SS auf LOW
2. SPI_TxData(0x06); // Write enable
3. SS auf High

Autor: Arduinoquäler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wichtiges aus dem Datenblatt:

----------------------------------------------------------------
9.1.2 Write Enable (06h)
The Write Enable command (Figure 9.3) sets the Write Enable Latch (WEL)
bit in the Status Register to a 1. The WEL bit must be set prior to 
every
Page Program, Sector Erase, Block Erase, Chip Erase, Write Status
Registers and Erase/Program Security Registers command. The Write Enable
command is entered by driving CS# low, shifting the instruction code 
“06h”
into the Data Input (SI) pin on the rising edge of CLK, and then
driving CS# high.
----------------------------------------------------------------

Fang doch mal mit den einfacheren Dingen wie Auslesen eines Status
Registers an. Wenn das funktioniert dann mach dich ans Schreiben.

Flash Speicher wird übrigens Page-weise geschrieben und gelöscht.
Wie das hier reagiert bei einzelnen Schreibvorgängen hab ich nicht
gesucht, aber warscheinlicht tut es einfach nichts.

Autor: Arduinoquäler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Achso, noch vergessen:

Dann hatte ich es schon geschrieben ....

Und nach dem Schreiben eines Blocks wird man noch eine gewisse
Zeit warten müssen bis der Chip wieder ansprechbar (lesbar) ist.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Write enable ist 0x06. Schau dir auch das Kapitel zu Write protection 
an.

Autor: Arduinoquäler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arduinoquäler schrieb:
> Flash Speicher wird übrigens Page-weise geschrieben und gelöscht.

Wenn du einzelne Bytes oder kleinere Datenmengen schreiben willst
musst du ein SPI EEPROM verwenden.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jungs,
danke für die Antworten.
Die Datenmengen sind nicht gerade klein. Paar MB pro Schreibzyklus.
Ich wollte erst beim Anfang nicht mit kompletter Page starten, sondern 
zum Üben nur ein Byte testen.
Die Statusregister auslesen klappt leider auch nicht :(
Habe am Rigol den SPI decoder. Und habe diesen jetzt in Betrieb 
genommen.
Wie vermutet, kommen meine Daten richtig an, bzw decodiert Rigol, das 
was ich zu senden meine.
An der MISO Leitung ist aber nicht viel los.
Ein leichtes Zucken auf etwa 1V und dann langsamer Abfall der Flanke. 
Als ob ein Pull-up fehlt.

Autor: Arduinoquäler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Die Statusregister auslesen klappt leider auch nicht :(

- Pin Belegung überprüfen
- Pin Direction überprüfen (speziell MISO)
- Clock / Data Phase überprüfen (gibt ja vier Möglichkeiten)
- Aufbau überprüfen

.... und Aufbau zeigen ....

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Heiliger Gott! MOSI und MISO vertauscht :))

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Heiliger Gott! MOSI und MISO vertauscht :))

Hehe, wie heißt es doch so schön: es ist noch kein meister vom Himmel 
gefallen ;)

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin schon etwas weiter, habe aber noch paar Fragen
Ich kann alle Adressen bis 0x000FFF beschreiben und auslesen.
Ab Adresse 0x001000 geht das Schreiben nicht mehr. Die Daten werden 
nicht gespeichert.
Hat Jemand eine Idee?

Und die andere Frage:
Auf Seite 43 ist Flash Memory Array.
Ich verstehe nicht ganz, wie das Array aufgebaut ist.
Sektor 1 ist 000000-000FFF
Sektor 2 ist dann 0x001000 - 0x001FFE ??
Mich irritiert das unter notes 000000h-000FFF (Sector Starting Address)
Sollte meiner Logik nach Sektor 1 heißen.

Danke schön

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei meinen SPI-Flashs gibt es einen geschützten Speicherbereich, den man 
nur mit anderen Commands beschreiben kann. Vllt ist das bei dir ähnlich.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kann dazu leider im Datenblatt nichts finden :(

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guck mal ab Seite 43.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, und bei meinem Flash muss ich erst löschen bevor ich beschreiben 
kann.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bin leider immer noch am Kämpfen :(
Den Flash lösche ich natürlich immer vorher, sonst lassen sich die 
Adressen nicht neu beschreiben.
Datenblatt S. 43 kenne ich natürlich, das meinte ich mit "Auf Seite 43 
ist Flash Memory Array."
Kann Jemand das Datenblatt für mich checken bitte, ich glaube, ich bin 
blind.
Bis Adresse 0x000FFF kann ich alles schreiben und lesen.
Nach 0x000FFF nehme ich natürlich die Adresse 0x001000
Ich danke vielmals.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, du bist blind :)

Ließ weiter ab s. 43 und denke dabei an meinen poSt zum Thema protected 
memory ;)

Achso und kontrolliere auch die Hardware, thema wp pin usw. Und u.u. 
noch die Software protection im Status register.

Der Flash gleicht meinen von den Features her.

: Bearbeitet durch User
Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank, ich sehe, was du meinst.
Ich habe den Flash nun komplett gelöscht und angefangen diesen aus zu 
lesen.
Adresse 0x00-0xFF ist Security Register 0. Die ausgelesenen Daten 
stimmen mit dem Daten im Datenblatt auf Seite 44 überein.

Also habe ich versucht, alle Security Register zu überspringen und bei 
der Adresse 0x4000 zu starten.
Ich habe sowohl nur ein Byte, wie auch die komplette Page beschrieben.
Leider ohne Erfolg.
Beim Auslesen kommt immer 0xFF raus.
Der Bereich ab 0x4000 hat keine protection Bits oder Ähnliches, richtig?

Ich schicke 0x06 (write enable) zuerst und warte ein wenig
dann 0x02(pagewrite)0x00 0x40 0x00 (Startadresse 0x004000) und die 
Daten.
Auslesen mit 0x03 0x00 0x40 0x00 dann dummybits. Das Lesen funktioniert, 
ich kann ja super den Security Register 0 auslesen.

Ich bin mir sicher, dass ich das richtig mache, nur eine Kleinigkeit 
habe ich übersehen.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Die ausgelesenen Daten stimmen mit dem Daten im Datenblatt auf Seite 44
> überein.
Hehe na sowas aber auch :) also lesen klappt ja dann schon mal.

Jürgen Trut schrieb:
> Der Bereich ab 0x4000 hat keine protection Bits oder Ähnliches, richtig?
Auf den ersten blick nicht.
Aber ließ dich mal ins Kapitel Status Register und protection bits ein. 
Und wie gesagt, Pins checken. Daran wirds wohl liegen.

Liest du eigentlich was ich schreibe? :> ich drösel dir das datasheet 
hier nicht auf.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Liest du eigentlich was ich schreibe? :>
Die WP und HOLD Pins sind nicht angeschlossen. Kann laut Datenblatt so 
bleiben.

>Auf den ersten blick nicht.
Die Securityregister gerade ausgelesen. Die defaultwerte sind drin 
SR1-0x02, SR2-0x04, SR3-0x70
Also sind Alle Block Protection Bits laut SR-1 nicht aktiv.

Ein Osziplott hilft wahrscheinlich nichts, oder? Die Befehle kommen 
anscheinend richtig an.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Die WP und HOLD Pins sind nicht angeschlossen. Kann laut Datenblatt so
> bleiben.
Habs grad durchgelesen, WP hat bei dir, anders als bei mir, einen 
Pullup. Der kann also nicht floaten. Aber HOLD soll anscheinend in 
deinem Fall auf high liegen.
Wenn das nicht funktioniert:

Jürgen Trut schrieb:
> Die defaultwerte sind drin
> SR1-0x02, SR2-0x04, SR3-0x70
Versuch noch möglichst alle protections raus zu machen, man kann ja mal 
was übersehen.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Ein Osziplott hilft wahrscheinlich nichts, oder?
Wenn du sagst, dass du scho beschrieben sowie gelesen hast, dann 
behaupte ich mal, dass deine comm funktioniert.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So Leute,
Scheiße :(
Ich habe jetzt den Register SR1 ausgelesen, war 0x02 drin. Das ist 
protection vom security register. Da wollte ich zwar nicht hin schreiben 
aber egal.
Danach in SR1 den Wert 0x00 geschrieben und später ausgelesen. 0x00 ist 
geblieben.
Also klappt das schon mal.

Flash komplett gelöscht, SR1 erneut überprüft. 0x00 ist geblieben.
Danach 256 Bytes ab Adresse 0x0740 bis 0x074FF geschrieben.
Vorher natürlich write enable (0x06)
Den Schreibvorgang soweit es geht am Oszi verfolgt. Sah alles gut aus.

Beim Auslesen aber immer noch 0xFF überall drin.

Keine Ahnung. Habe 10 Stk davon da, und schon mal ein ausgetauscht. Hat 
nichts gebracht.
Andere Lock Bits sehe ich da nicht. Die, die da waren, habe ich 
deaktiviert.

@Reginald
Welchen Flash nutzt du?

Falls jemand noch eine Idee hat, her damit.

Vielen Dank

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Keine Ahnung. Habe 10 Stk davon da, und schon mal ein ausgetauscht. Hat
> nichts gebracht.
Hehe, habe ich zu Anfang dauernd gemacht, bis ichs geblickt hatte.

Jürgen Trut schrieb:
> @Reginald Welchen Flash nutzt du?
Den von winbond w25q80bv

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Den von winbond w25q80bv
Der ist aber sehr ähnlich zu meinem
Alle Befehle usw sind die gleichen.

Kannst du bei jeder Adresse mit dem Schreiben starten?
ich habe jetzt mehrere ausprobiert. 0x074100 Als Startadresse und die 
Page voll gemacht.
Beim Auslesen leider immer die gleiche Kotze. 0xFF
Statusregister lesen und schreiben geht (sorry für Wiederholung)
Keine Ideen mehr.

Das Einzigste was noch sein könnte:
Das Flash ist ein einem Evalboard dran. Die Leiterbahnlänge könnte etwas 
kritisch sein und die Verbindung Flash <-> Board ist mit Fädeldraht.
Am Flash direkt ist ein 100nF Kerko dran.
Das klingt noch ein wenig logisch, spricht aber dagegen, dass ich die 
Register schreiben und lesen kann.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, und in den security sektor 0 kann ich die Daten schreiben. 
zumindestens eine Page Adresse 0x00 bis 0xFF.
Ich kann die Daten auslesen, dann sind das auch die Richtigen Daten 
drin. Ich kann die so oft ich will auslesen.
Nach dem Strom abklemmen sind die Daten wieder die Alten. Wie im 
Datenblatt bei security sektor 0 abgegeben.
Sehr komisch das Ganze.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Der ist aber sehr ähnlich zu meinem
> Alle Befehle usw sind die gleichen.
Ja, ich vermute das ist so, weil es ja einen JEDEC-Standard gibt. So 
kannst du die Dinger einfach untereinander austauschen, wenn du mal 
einen Größeren brauchst.

Jürgen Trut schrieb:
> Kannst du bei jeder Adresse mit dem Schreiben starten?
Dazu gibts ein Kapitel im Sheet. Kann mich nicht mehr genau erinnern 
aber ich glaube, ja. Man muss da nur etwas besonderes beachten. Aber ich 
schreibe grundsätzlich immer an den Anfang einer Page und schreibe diese 
dann auch voll. Das war so für mich leichter zu handhaben.

Jürgen Trut schrieb:
> Beim Auslesen leider immer die gleiche Kotze. 0xFF
> Statusregister lesen und schreiben geht (sorry für Wiederholung)
Ja nee, is ja gut, immer gegenprüfen, würde ich auch. Ich lese zb bei 
jedem Hochfahren erstmal die IDs aus dem Gerät und vergleiche sie. So 
weiß ich ob ich den Flash überhaupt ansprechen kann.

Jürgen Trut schrieb:
> Das Flash ist ein einem Evalboard dran. Die Leiterbahnlänge könnte etwas
> kritisch sein und die Verbindung Flash <-> Board ist mit Fädeldraht.
> Am Flash direkt ist ein 100nF Kerko dran.
> Das klingt noch ein wenig logisch, spricht aber dagegen, dass ich die
> Register schreiben und lesen kann.
Hehe, würde ich jetzt mal spontan sagen, dass es nicht daran liegt. 
Meiner hat nicht mal n Kerko dran und auch über 20cm-Jumperkabel 
verbunden :) Rennt auf 90MHz und bisher konnte ich keine 
Übertragungsfehler wahrnehmen und dabei wird bei jedem Hochfahren der 
Flash ausgelesen, etwa 300kB :> Wenn da was nicht stimmen würde, würde 
ich es sofort am TFT sehen.
Hatte auch zu Anfang die gleichen Probleme. Vor kurzem habe ich den 
Aufbau geändert und wieder die selbe Leier. Die HOLD und WP Pins habe 
ich auf V+ gelegt, die Statusregister setze ich so, dass nichts mehr auf 
Protected steht, beschreibe nur die Sektoren, auf denen keine Security 
Register oder Ähnliches drauf liegt.
Hast du schonmal einen Chip-Erase durchgeführt? Wenn du genug von den 
Dingern hast, würde ich einfach mal vorher draufloslöschen. Die Dinger 
halten eh ewig und kosten nichts. Wenn 0xFF rauskommt, sollte der 
Bereich gelöscht sein. Aber sicher ist sicher. Ich Lösche immer den 
Kompletten Chip, wenn ich mal ein neues Objekt auf den Chip schreiben 
will.
Ich schick dir mal meinen Code, ist zwar nicht viel, aber vllt hilft es 
ja.

EDIT: Bist ja als Gast drin, so wird das nix :)

: Bearbeitet durch User
Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bins wieder.
Bis jetzt bleibt alles komisch.
Ich habe den Flash mal komplett, mal Stückweise gelöscht.
Nach dem Löschen ist beim erneutem Auslesen alles 0xFF.

Schalte ich aber die Spannung ab und wieder an, und lese eine beliebige 
Page von Anfang an aus, erhalte ich Daten, die nicht 0xFF sind.
Es ist sogar egal, welche Page ich nehme. Die sind immer gleich. (Außer 
Security Sektor 0)
Das wird ausgelesen:
53 46 44 50 00 01 02 FF 00 00 01 09 80 00 00 FF EF 00 01 04 80 00 00 FF 01 00 01 00 A4 00 00 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF E5 20 F1 FF FF FF FF 03 44 EB 08 6B 08 3B 80 BB EE FF FF FF FF FF FF FF FF FF FF FF 0C 20 10 D8 00 FF 00 FF 15 0D 00 05 05 07 00 24 FF FF FF FF 16 3B 25 00 20 00 08 12 11 20 13 01 11 4A 00 08 12 11 20 13 01 A5 A0 FF FF C8 00 07 03 02 08 00 00 FF FF FF FF FF 01 4D 05 00 01 00 0D 05 15 20 14 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 25 EC 60 81 A3 28 80 06

Verstehe das leider echt nicht.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen Trut schrieb:
> Schalte ich aber die Spannung ab und wieder an, und lese eine beliebige
> Page von Anfang an aus, erhalte ich Daten, die nicht 0xFF sind.
Das darf natürlich nicht sein. Dann musst du dir nochmal dein spi 
anschauen. Wenn du mir deine eMail Adresse zufaxt schicke ich dir meinen 
Code,  da is spi auch dabei, läuft auf einem stm32 f429.

Ps: das faxen War natürlich ein Witz höhö

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achja, wie man sehen kann, sind das die Daten, die auf Seite 44 unter
"Table 7.4 Serial Flash Discoverable Parameter Definition Table"
stehen.
Gelesen habe ich in diesen Fall von 0x004000 bis 0x0040FF.

Das sind die Daten
The S25FL132K and S25FL164K features a 256-Byte Serial Flash 
Discoverable Parameter (SFDP) space,
located in Security Register-0, that contains information about the 
device operational capabilities such as
available commands, timing and other features.

Aber was haben die bei der Adresse 0x004000 verloren?
Security Register-0 ist 0x000000 bis 0x0000FF. (Security Register 
Addresses Seite 44)

Dass ich wirklich die Adresse 0x004000 auslese, sehe ich auf dem Oszi. 
Er kann mir bequem die SPI Daten decodieren.

Autor: Jürgen Trut (Gast)
Datum:
Angehängte Dateien:

Bewertung
-1 lesenswert
nicht lesenswert
Danke für das Codeangebot.
Ich weiß nicht, ob ich den gebrauchen kann. Ist wirklich nicht unnett 
gemeint.
Die Daten sind ja nach Datenblatt.
Im Anhang ist der Plot, wo ich die Daten aus 0x004001 auslese.
Da ist die 0x46  als Wert drin.
Fällt dir am Oszibild evtl. was auf?

Autor: Jürgen Trut (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Und so sieht ein einfaches Write Enable (0x06) aus.
Damit man die Timing meiner SPI genau sehen kann.
Genau an den Flash Pins gemessen.

Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mich jetzt angemeldet, warte auf die Bestätigungsmail vom Forum.
Würde Dein Code doch gerne sehen.
Weiß sonst echt nicht weiter.
Irgendwie Mist ist das.

Autor: Bastian W. (jackfrost)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir den Bereich wo die Werte anders werden mal genauer an. Es ist 
etwas schwer zu erkennen , aber es sieht so aus als würden die Pegel 
einmal bei steigender Flanke und dann bei fallender Flanke sich ändern. 
Das darf ja eigentlich nicht sein. Kann es sein das die high Pegel in 
dem Bereich etwas niedriger sind ?

Gruß JackFrost

: Bearbeitet durch User
Autor: Jürgen Trut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@JackFrost
meinst du den Bereich, wo MISO das erste Mal aktiv wird.
Keine Ahnung, Der Flash fängt einen halben Clock Takt früher an.
Das sieht aber nach "egal" aus. Ist zwar nicht nach Datenblatt, aber in 
den Bereich sind die MISO Daten eh dont carry.
Bei Fallender CLK Flanke ist der Pegel vom MISO richtig.
Denke nicht, dass das der Fehler ist. Und wenn schon, kann ich das eh 
nicht beeinflussen.

Autor: Jürgen T. (juergent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hasse solche Probleme.
In 99,998% liegt der Fehler natürlich beim Programmierer.
Aber warum das Im Datenblatt nicht genau drin steht, bzw irgendwo 
versteckt ist.. Keine Ahnung.
Dass Write Enable aktiviert werden soll und die SS Leitung auf Low, was 
jeder Vollidiot weiß, steht auf jeder Seite.
Hardwaremäßig kann kein Fehler sein.
Oszibilder zeigen, dass alles so läuft, wie man das sich denkt.
Die Befehle sind auch anscheinend auch richtig, denn ich finde nichts 
anderes.
Aber ein läuft einfach NICHT. Schon seit mehreren Tagen kann ich das als 
erfahrener (selbst ernannt) Berufsprogrammierer nicht in Betrieb nehmen.

Herstellersupport reagiert nicht, bzw lässt sich Wochen Zeit, um dann zu 
fragen, ob das Problem sich gelöst hat. Weil nach paar Wochen ist das 
Problem oft gelöst, und man braucht nicht mehr helfen.

: Bearbeitet durch User
Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das könnte bei dir u.u. schon an den Timings liegen. Ich benutze nicht 
den continues Mode, nach jedem Byte wird alao einmal kurz cs auf high 
gelegt.
Bin nicht mehr um Labor, schicke dir den Code morgen.

Autor: Jürgen T. (juergent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich benutze nicht den continues Mode, nach jedem Byte wird alao einmal kurz >cs 
auf high gelegt.
meinst du beim Lesen oder schreiben?
Dann muss aber der Befehl 0x02 zum Schreiben und 0x03 zum Lesen inkl. 
Adresse mitgeschickt werden.
Weil, wenn du CS hoch reißt, ist es erst mal vorbei.
Vorausgesetzt, ich habe dich richtig verstanden.

Jedenfalls habe ich schon beides Probiert.
Nur ein Byte schreiben und lesen, sowie komplette Page.

Nach dem Löschen alles 0xFF, jedoch nach Strom aus&an in jeder Page 
Security Register Daten.
Ist langsam wirklich lächerlich.
Ich wüsste nicht mal, was ich noch probieren KÖNNTE.

Zum Kotzen ist noch,
ich habe gerade Bit 5 beim SR2 zum Testen aktiviert.
Jetzt ist der SR2 immer 0x24 und ich kriege es nicht wieder zurück. 
Weder mit Chip erase, noch mit neuem Wert ins Register schreiben.

: Bearbeitet durch User
Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen T. schrieb:
> meinst du beim Lesen oder schreiben?
Nach jedem Byte, egal ob senden oder schreiben. Ich benutze keinen DMA, 
da das Flash nur beim Booten benutzt wird. So habe ich immer eine kleine 
Pause zwischen den einzelnen Bytes. Natürlich geht dann die Transferrate 
etwas runter. Aber zum ausprobieren wirds ja bei dir reichen, dann 
kommst du vllt ein Stück näher an die Problemlösung.

Jürgen T. schrieb:
> Weil, wenn du CS hoch reißt, ist es erst mal vorbei.
Nein, CS auf high bedeutet nur, dass keine Bytes gesendet oder empfangen 
werden sollen.

Jürgen T. schrieb:
> Weder mit Chip erase, noch mit neuem Wert ins Register schreiben.
Du kannst ja auch mal die Register meines und deines Flashs vergleichen. 
Wenn die identisch sind, kannst das aus meinem Code ja erstmal auch so 
übernehmen. Wie gesagt, bei mir funzt es.

Ich schick dir gleich die Files.

Autor: Jürgen T. (juergent)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Reginald
Danke für den Code.
Das sieht bei mir vom Prinzip leider genau so aus.
Ich muss jetzt mit diesem Flash aufgeben, und mit einen anderen kaufen.
Ich sehe da keinen Sinn erst mal weiter zu machen.

Kannst du mit das mir der CS Leitung noch mal erzählen. Ich habe es 
leider nicht ganz verstanden, wie das funktioniert.
Kannst du beim Lesen den Lesebefehl schicken, dann die Startadresse, 
dann liest du den ersten Byte aus.
Dann machst du CS auf high.
Irgendwann mal wieder auf low, und kannst nächstes byte weiter 
auslesen???
Ohne "den Lesebefehl schicken, dann die Startadresse"?

Danke

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cs aktiviert einfach nur den slave. Soll heissen:
Achtung, ich muss jetzt das clk signal abhorchen. Wenn clk das nächste 
mal auf high/low geht, muss ich anfangen MOSI auszuwerten und ggf MISO 
losschicken.
Wenn cs wieder auf high geht, horcht der slave nur noch cs ab. Cs wieder 
low -> gleiches Spiel von vorn.

Jürgen T. schrieb:
> Das sieht bei mir vom Prinzip leider genau so aus.
Nein eben nicht. Dein cs bleibt für länger als ein Byte auf low. Was ja 
nicht falsch ist aber vllt passt ja was an deinen Timings nicht.

Ich würde dir empfehlen meinen spi Code auszuprobieren. Dann weißt du 
immerhin ob hier der Hund begraben ist.

Edit: du siehst dann auch den unterschied zwischen deiner und meiner 
Methode, wenn du dir das auf dem Oszi anschaust.

: Bearbeitet durch User
Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gab es hier noch neue Erkenntnisse?
Habe jetzt 4 Tage den gleichen Mist durch.. Mit Flashrom kann ich die 
beschreiben, nur der Stm32 will das ganze trotz sauberem Spi Output im 
Scope nicht.

Ich versuche das jetzt nochmal mit dem Drivestrength und 
serienwiderständen..dann weiß ich auch nicht weiter.

Habe w25q32fvsig.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp K. schrieb:
> Habe w25q32fvsig.
Das ist ja fast der gleiche den ich hab. Schau dir die Tipps hier durch, 
die ich gegeben habe.

Philipp K. schrieb:
> Ich versuche das jetzt nochmal mit dem Drivestrength und
> serienwiderständen
Edit: Meiner ist elektrisch mit 20cm Jumperkabeln angebunden und rennt 
mit 90MHz. Hab keinerlei Hühnerfutter dran.

: Bearbeitet durch User
Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
> Das könnte bei dir u.u. schon an den Timings liegen. Ich benutze nicht
> den continues Mode, nach jedem Byte wird alao einmal kurz cs auf high
> gelegt.

DAS ist bei SPI Flash tödlich. Der CS muss natürlich während einer 
Transaktion dauerhaft auf Low liegen. Deshalb nimmt man dafür nicht den 
Hardware CS sondern einen GPIO.

Autor: Reginald L. (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jim M. schrieb:
> DAS ist bei SPI Flash tödlich.
Warum?

Jim M. schrieb:
> Der CS muss natürlich während einer Transaktion dauerhaft auf Low liegen
Tut er ja.

Jim M. schrieb:
> Hardware CS sondern einen GPIO.
Hä?

Autor: Philipp K. (philipp_k59)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
> Edit: Meiner ist elektrisch mit 20cm Jumperkabeln angebunden und rennt
> mit 90MHz. Hab keinerlei Hühnerfutter dran.

Das Problem ist ja das der Logik Analyzer ein vorbildliches Timing aller 
Eingänge anzeigt, es kommt nur nix raus am Miso(Keine JEDEC Oder Vendor 
ID).. Sporadisch halt schon wenn man 20 mal immer wieder das gleiche 
abfragt. Wenn ich am LA den SPI  Viewer zuschalte zeigt der auch alle 
Bytes richtig an.

Ich versuch mal weiter!

EDIT: Der B80V hat übrigens kein Drive Strength Register..  meine 
Theorie das vielleicht der Output Driver mit 25% Standard Strength zu 
gering ist um Die Leitung hoch/runterzuziehen. Drive Strength hab ich 
sonst noch nix von gehört, daher eine Vermutung.

: Bearbeitet durch User
Autor: Philipp K. (philipp_k59)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, Fehler bei mir gefunden.. funktioniert jetzt mitm Stm32F030.

Der hat wohl irgendwo 5V abbekommen, die HIGH LOW Flanken des SPI waren 
zu unsauber. Funktioniert jetzt mit neuem IC bei gleichem Programm.

Rein optisch hat alles sauber funktioniert von Debugging bis 
Logikanalyzer.. ich habe dann erst gemerkt das was schief läuft als die 
SPI Diagramme zwischen STM32 und Flashrom Brenner gleich aussahen, nur 
auf dem board kein Signal am Miso angekommen ist.

Das scope hat dann merkwürdiges angezeigt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.