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
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
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.
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.
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.
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.
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 ....
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 ;)
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
Bei meinen SPI-Flashs gibt es einen geschützten Speicherbereich, den man nur mit anderen Commands beschreiben kann. Vllt ist das bei dir ähnlich.
Achja, und bei meinem Flash muss ich erst löschen bevor ich beschreiben kann.
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.
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
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.
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.
> 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.
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.
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.
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
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
>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.
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.
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
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:
1 | 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.
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ö
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.
Angehängte Dateien:
-
DS1Z_QuickPrint1.png
52 KB
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?
Angehängte Dateien:
-
DS1Z_QuickPrint2.png
41 KB
Und so sieht ein einfaches Write Enable (0x06) aus. Damit man die Timing meiner SPI genau sehen kann. Genau an den Flash Pins gemessen.
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.
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
@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.
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
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.
>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
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.
@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
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
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.
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
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.
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ä?
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
Angehängte Dateien:
-
DSC_0247.JPG
240 KB
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.