SD card über sdio interface mit STM32 HAL

wenn ich den Transfertakt runterdrehe dann klappts, werde mich wohl mehr 
mit der Initialisierung beschäfftigen müssen.

1

  uSdHandle.Init.ClockDiv            = 8; // SDIO_TRANSFER_CLK_DIV;

Hat hier jemand Erfahrung mit dem SDIO vom F4?
Ich habe nochmal die Initialisierung näher betrachtet. Das Board ist ein 
STM32F407VET6 "Black", das ist wegen günstig recht verbreitet.
Der SDIO clock divider muss hier >=3 sein, damit ist der Takt 48 / 5 MHz 
= 9,6 MHz. Beim nächstkleineren Teiler und 12 MHz bekomme ich CRC Fehler 
beim Schreiben. Ich vermute das der Takt auch von der SDC abhängt, aber 
wie soll man den Einstellen wenn man verschiedene Karten hat? Geht das 
aus der SDC class oder einer der Infos die man lesen kann hervor?

ok, danke, da habe ich noch nicht nachgesehen bzw. sollte der HAL code 
das machen.
Für das Board gibt es auch einen Arduino core, da wird mit 24 MHz 
initialisiert und das scheint auch zu funktionieren. Das könnte ich zum 
Test auch noch ausprobieren.

so sieht der init aus:

1

  /* Common GPIO configuration */

2

  gpio_init_structure.Mode      = GPIO_MODE_AF_PP;

3

  gpio_init_structure.Pull      = GPIO_PULLUP;

4

  gpio_init_structure.Speed     = GPIO_SPEED_HIGH;

5

  gpio_init_structure.Alternate = GPIO_AF12_SDIO;

6

7

  /* GPIOC configuration */

8

  gpio_init_structure.Pin = GPIO_PIN_8 | GPIO_PIN_9 | GPIO_PIN_10 | GPIO_PIN_11 | GPIO_PIN_12;

Der Cube code initialisert mit GPIO_SPEED_FREQ_VERY_HIGH, habe ich 
geändert aber das Ergebnis ist gleich, max. 12 MHz für lesen, 9,6 MHz 
für lesen/schreiben.
Hardware Pullups von 10k sind auch vorhanden, ich habe auch GPIO_PULLUP 
und NOPULLUP probiert.

1

  /* Enable SDIO clock */

2

  __HAL_RCC_SDIO_CLK_ENABLE();

3

4

  /* Enable DMA2 clocks */

5

  __DMAx_TxRx_CLK_ENABLE();

6

7

  /* Enable GPIOs clock */

8

  __HAL_RCC_GPIOC_CLK_ENABLE();

9

  __HAL_RCC_GPIOD_CLK_ENABLE();

10

11

  /* Common GPIO configuration */

12

  gpio_init_structure.Mode      = GPIO_MODE_AF_PP;

13

  gpio_init_structure.Pull      = GPIO_PULLUP;

14

  gpio_init_structure.Speed     = GPIO_SPEED_FREQ_VERY_HIGH;

15

  gpio_init_structure.Alternate = GPIO_AF12_SDIO;

16

17

  /* GPIOC configuration */

18

  gpio_init_structure.Pin = GPIO_PIN_8 | GPIO_PIN_9 | GPIO_PIN_10 | GPIO_PIN_11 | GPIO_PIN_12;

19

20

  HAL_GPIO_Init(GPIOC, &gpio_init_structure);

21

22

  /* GPIOD configuration */

23

  gpio_init_structure.Pin = GPIO_PIN_2;

24

  HAL_GPIO_Init(GPIOD, &gpio_init_structure);

Es funktioniert, danke Hilfe von stevestrong vom stm32duino Forum. Für 
die Nachwelt:
Zum SDIO gibt es einige Errata, z.B. funktionert hardware flow control 
mit dem Datenfifo nicht. Im debug build macht der HAL Code zuviele 
Funktionsaufrufe und der Sendefifo läuft leer. Im release build werden 
die wegoptimiert und der Datentransfer läuft mit vollen 24 MHz im 4 Bit 
mode.

Darf ich mal 'was einwerfen?

Ich lese hier jede Woche von schwierigen Problemen mit STM32, die am 
Ende mit Verweis auf die Errata behoben werden.

Auch ich hatte gleich an meinem ersten Wochenende zwei unerwartete 
Probleme:

Beim ersten Problem war die Konfiguration des Taktgeber (made by Cube 
MX) so falsch, dass der µC sich während dessen aufhing. Daher versuchte 
ich die Programmierung ohne HAL - übrigens mit Erfolg.
Direkt danach funktionierte die I²C Schnittstelle nicht, obwohl ich mich 
an die krude Sequenz aus der Application Note hielt. Ursache war ein 
Bug, der im Errata beschrieben war.

Daraus lerne ich: Dass Errata Dokument und die Application Notes sind 
bei STM32 offensichtlich Pflichtlektüre. Nicht nur bei mir.

Ich weiß, dass es für AVR auch Errata gibt. Aber die habe ich in 10 
Jahren noch nie gebraucht. Ich hatte nur einmal aus Neugier herein 
geschaut und dabei bemerkt, dass die für mich relevanten Fehler bereits 
vor vielen Jahren behoben wurden.

Bei STM32 scheinen zahlreiche Fehler hingeben lange zu bestehen. Und bei 
jedem neuen Modell werden die Errata Dokumente gefühlt länger statt 
kürzer.

Dennoch heißt es hier immer wieder, man solle Anfängern nicht die AVR µC 
empfehlen, weil bei STM32 ja alles einfacher und besser sei. Wo ist die 
Logik darin?

Stefanus F. schrieb:
> Dennoch heißt es hier immer wieder, man solle Anfängern nicht die AVR µC
> empfehlen, weil bei STM32 ja alles einfacher und besser sei. Wo ist die
> Logik darin?

die STM32 sind nicht unbedingt einfacher, das behaupte ich schon nicht 
mehr. Aber sie (und andere Cortex-M natürlich auch) haben deutlich 
komplexere und leistungsfähigere Peripherie. Einige Probleme scheinen 
daher zu kommen das da verschiedene Clockdomains zusammenarbeiten und 
die Synchronisation zickig ist. Das sowas schon bei 'simplen' Sachen wie 
SPI zuschlägt macht es für Anfänger nicht einfach. Daher empfehle ich 
gerne die LPC von NXP (bin nicht mit denen verwandt oder verschwägert) 
weil die Peripherie viel mehr 32 Bit breite nutzt und irgendwie 
intuitiver zu programmieren ist.
Die STM32 haben für mich die Nase in Sachen Grafik vorne und das 
STM32F407VE Board bekommt man für ca. 10€ und für noch einen 10er gibts 
ein TFT dazu das man nur aufstecken braucht. Ansteuerung per FSMC 
sauschnell. Da gibt es zur Zeit nichts vergleichbares.
In mbed wird für STM die HAL verwendet und deshalb habe ich das jetzt 
auch genutzt. Da diese SW auch von ST kommt sehe ich das als Referenz 
und Erratas sollten darin auch berücksichtigt sein. Ob das immer so ist 
weiss ich allerdings nicht. Und bei diesem letzten Fehler war das 
Problem der sonst saubere Aufbau mit mehreren Schichten, nur im Debug 
build zu langsam.
Ich weiss das über HAL viel gemeckert wird, wenn ich da so blödsinnige 
Abfragen sehen verstehe ich auch warum, aber so ein SDC interface würde 
ich nicht in 3 Tagen aus Datenblättern zusammenschreiben.

1

if((Timeout == 0U)||((HAL_GetTick()-tickstart) >=  Timeout))

Also wenn die Funktion ein Timeout 0 übergeben bekommt wird immer ein 
Fehler gemeldet, auch wenn es kein Timeout gab.
Die Jungs von stm32duino haben im libmaple core das ohne HAL 
hinbekommen, aber da haben die sicher ein paar Stunden an der 
Implementierung gesessen.

ich habe noch ein Problem mit dem SDIO Interface:
wenn ich eine Sequenz

1

init_sdio();   // ok

2

deinit_sdio(); // ok

3

init_sdio();   // not ok

habe dann funktioniert das erste Initalisieren, aber folgende schlagen 
fehl. Im Init wird der 4 Bit SDIO mode aktiviert, dazu wird in der HAL 
das SCR abgefragt ob die Karte das unterstützt. Beim ersten Aufruf nach 
einem Reset liefert das SCR Lesen korrekte Werte, bei folgenden hängt 
der call SD_Find_SCR() in einer Endlosscheife und bekommt nicht die 
abgefragten Flags.
Find_SCR löst ein Kommando 51 aus.
https://github.com/ARMmbed/mbed-os/blob/a5b757312d875521a06de42d898d5d00a86b1a0e/targets/TARGET_STM/TARGET_STM32F4/device/stm32f4xx_hal_sd.c#L2789
Wenn ich wie hier vorgeschlagen 
https://blog.frankvh.com/2011/09/04/stm32f2xx-sdio-sd-card-interface/ 
das Find_SCR() einfach weglasse und in den WideBus Mode umschalte dann 
funtioniert auch alles.
Was mich eben nur wurdert das es nach dem Reset ok ist, also müsste das 
init etwas verstellen das ein zweites init fehlschlägt (deinit kann ich 
auch weglassen, gleicher Fehler).
Kennt jemand das Problem? Fragen zu dem Problem habe ich schon gefunden, 
aber noch keine guten Antworten.
Das deinit() macht ein SD PowerOff, das init() ein PowerOn, damit müsste 
die Karte doch resettet werden?