STM32 QSPI MT25QL128A

[Anatol G. (tola511)]

Hallo Leute,

ich habe gerade versucht, meinen Qspi MT25QL128A auf einem STM32U599 
Custom Board zum Laufen zu bringen, aber leider habe ich bisher keinen 
Erfolg gehabt. Im CubeProgrammer habe ich den Qspi im External Loader 
ausgewählt, aber es erscheint die Meldung "data read failed". Im Code 
musste ich die Funktionen aus diesem Code: 
https://github.com/EPFLRocketTeam/FlashDriver (N25Q512A13GSF40E) 
übertragen und habe versucht, sie so gut wie möglich auf den U599 
anzupassen, da die HAL-Befehle nicht mehr die gleichen sind. Außerdem 
habe ich die Header-Dateien vom N25Q128A verwendet, da diese auch für 
den MT25QL128A funktionieren sollten. Ich konnte keine speziellen 
Header-Dateien für den MT25QL128A finden.

In der Cube IDE habe ich den Qspi auch in der Debug Config aktiviert 
(Enable = True, Init = False). Wenn ich den Code ausführe, bleibt er 
beim Auto_polling im Error_Handler hängen. Das Ziel dieser ganzen Aktion 
ist es, Bilder für den TouchGfx zu speichern und abzurufen.

[J. S. (jojos)]

Wenn der external Loader den Chip kennt und es damit nicht geht, dann 
müsste es ja ein Hardwareproblem sein. Bei den Disco Boards funktioniert 
es mit dem external Loader.

[Anatol G. (tola511)]

Ich habe nochmal im Datenblatt nachgeschaut und da ich den 
MT25QL128ABA1ESE-0SIT nutze sollte ein Pull-up auf DQ3 sein. Dieser war 
nicht drauf, aber nach dem einlöten hat sich nichts geändert.Ich habe 
nochmal gepüft ob die GPIOs richtig sind. Also der External Loader ist 
unabhängig vom code? Machen evtl. die 33ohm an den pins probleme?

[J. S. (jojos)]

der external Loader lädt einen Stub, also einen Code der den externen 
Flash programmiert, in das RAM und ist damit unabhängig vom Code der 
geflasht wird.

[Anatol G. (tola511)]

Sehr gut, also liegt das problem wirklich an der Hardware. Sieht aber 
richtig aus. Auf dem Plan ist es nicht aufgezeichnet, aber der Vcc liegt 
an 3,3V. ich habe die pins auch so angeschlossen wie der CubeMX es 
vorgeschlagen hat.

[Wastl (hartundweichware)]

Anatol G. schrieb:
> Sehr gut, also liegt das problem wirklich an der Hardware.

Viele Leute die hier mit einem Problem an SPI- oder I2C-
EEPROMs daherkommen verkennen die Problematik dass so ein
Baustein im Betrieb sehr hohe Peaks in der Stromaufnahme
haben. Solche EEPROMs brauchen eine stabile Versorgung,
auch wenn der mittlere Strom sehr gering ist. Daher ist
ein Abblock-Kondensator dringend erforderlich.

Ob das bei dir schon berücksichtigt ist (evtl. nicht
bestückt?) weiss ich naturgemäss nicht. Ich sehe gerade:
Auf deinem Schaltplan ist aber 3.3V gar nicht am EEPROM
angeschlossen. Soll das so sein oder gibt es "geheime"
Leitungen?

[Anatol G. (tola511)]

Wie gesagt im Plan fehlt es noch, aber 3,3V liegen am Vcc vom QSPI an. 
Und der 100nF ist auch bestückt.