stm32 FatFS stranges Problem

[Heiko J. (heiko_j)]

Hallo,

ich versuche gerade mein Nucleo-F767ZI dazu zu überreden eine SDCARD zu 
mounten. Dabei kommt es zu einem strangen Problem.

Sobald ich f_mount irgendwo im Code aufrufen will bleibt der Nucleo nach 
dem Flashen hängen, und zwar noch bevor der Code überhaupt ausgeführt 
wird.
Es rumpelt dabei so heftig das der stlink das ttyACM0 verliert und ich 
auch nicht mehr neu flashen kann bis ich den stlink aus und wieder 
eingesteckt habe. Lasse ich f_mount auskommentiert läuft alles wie 
gehabt. Ich würde es ja verstehen wenn es rumpelt sobald f_mount 
aufgerufen wird, aber dazu kommt es ja gar nicht. Nicht mal mehr die 
Versionsausgabe gleich nach dem Start über die UART spuckt das Ding in 
diesem Fall aus. Vor allem das sich sogar der stlink dabei weghängt 
finde ich ausgesprochen strange.

Mit freundlichen Grüßen
Heiko

  FATFS fs;
  FRESULT fret;

  fprintf(stdout,"f_mount ... ");
  osDelay(500);

  //fret = f_mount(&fs, "0:", 1);

  osDelay(500);
  fprintf(stdout," RC: %u \n", fret);

st-flash --serial 303636454646353635313534363637383637313932323535 write build/stm32f767zi_nucleo_144.bin 0x8000000
st-flash 1.5.1-31-g625f4cd
2019-08-03T22:52:49 INFO common.c: Loading device parameters....
2019-08-03T22:52:49 INFO common.c: Device connected is: F76xxx device, id 0x10016451
2019-08-03T22:52:49 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2019-08-03T22:52:49 INFO common.c: Attempting to write 115584 (0x1c380) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08018000 erasedEraseFlash - Sector:0x3 Size:0x8000 
2019-08-03T22:52:50 INFO common.c: Finished erasing 4 pages of 32768 (0x8000) bytes
2019-08-03T22:52:50 INFO common.c: Starting Flash write for F2/F4/L4
2019-08-03T22:52:50 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 17280
2019-08-03T22:52:52 INFO common.c: Starting verification of write complete
2019-08-03T22:52:53 INFO common.c: Flash written and verified! jolly good!
heiko@heiko-desktop:/tmp/convert/stm32f767zi_nucleo_144_repo/stm32f767zi_nucleo_144/STM32CubeMX/stm32f767zi_nucleo_144$ make flash
st-flash --serial 303636454646353635313534363637383637313932323535 write build/stm32f767zi_nucleo_144.bin 0x8000000
st-flash 1.5.1-31-g625f4cd
2019-08-03T22:53:11 INFO common.c: Loading device parameters....
2019-08-03T22:53:11 INFO common.c: Device connected is: F76xxx device, id 0x10016451
2019-08-03T22:53:11 INFO common.c: SRAM size: 0x80000 bytes (512 KiB), Flash: 0x200000 bytes (2048 KiB) in pages of 2048 bytes
2019-08-03T22:53:11 INFO common.c: Attempting to write 115584 (0x1c380) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08018000 erasedEraseFlash - Sector:0x3 Size:0x8000 
2019-08-03T22:53:13 INFO common.c: Finished erasing 4 pages of 32768 (0x8000) bytes
2019-08-03T22:53:13 INFO common.c: Starting Flash write for F2/F4/L4
2019-08-03T22:53:13 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2019-08-03T22:53:16 ERROR flash_loader.c: flash loader run error
2019-08-03T22:53:16 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1
Makefile:429: die Regel für Ziel „flash“ scheiterte
make: *** [flash] Fehler 255

[zufaulzumanmelden (Gast)]

Stranges Problem? Das musst du mir explainen.

scnr, aber irgendwann ist auch mal genug, mit dem Denglish

[Heiko J. (heiko_j)]

Was für eine hilfreiche Antwort !
Danke sehr !

[Junger Mann (Gast)]

Klingt so als ob da irgendwas überschrieben wird, was nicht 
überschrieben werden sollte. Hast du irgendwo riesige Buffer angelegt?

[Heiko J. (heiko_j)]

Junger Mann schrieb:
> Klingt so als ob da irgendwas überschrieben wird, was nicht
> überschrieben werden sollte. Hast du irgendwo riesige Buffer angelegt?

Hab ich mir auch schon überlegt und deshalb in der STM32CubeMX den Stack 
und Heap von 0x200/0x400 auf 0x400/0x800 vergrößert. Hat aber auch 
nichts gebracht. Würde der stlink nicht dabei abschmieren könnte ich 
wenigstens mit dem Debugger gucken. Bin am überlegen ob ich nicht in 
einem nicht genutzten IRQ handler testweise mal den aufruf rein mache, 
damit der Code zwar im binary ist, aber nicht aufgerufen wird und der 
optimizer ihn nicht trotzdem raus schmeißt. Nächster Versuch wäre Heap 
und Stack bis zum Anschlag aufzudrehen. RAM hat das Trum ja genug.

Gruß Heiko

[Heiko J. (heiko_j)]

Ich glaub ich schmeiß nachher wenn ich wieder daheim bin mal den nm an 
und vergleich mal was wieviel frisst.

[Jim M. (turboj)]

Heiko J. schrieb:
> Es rumpelt dabei so heftig das der stlink das ttyACM0 verliert

Schaltplan, bitte.

Der ST-Link hängt IIRC an der selben 3,3V Quelle, und Dein Problem kling 
so als würde die einbrechen - z.B. durch Kurzschluss oder Überlast.

Eine SD Karte darf in den langsameren Modi aber nur 100mA ziehen.

[Heiko J. (heiko_j)]

Jim M. schrieb:
> Heiko J. schrieb:
>> Es rumpelt dabei so heftig das der stlink das ttyACM0 verliert
>
> Schaltplan, bitte.
>
> Der ST-Link hängt IIRC an der selben 3,3V Quelle, und Dein Problem kling
> so als würde die einbrechen - z.B. durch Kurzschluss oder Überlast.
>
> Eine SD Karte darf in den langsameren Modi aber nur 100mA ziehen.

Die SD-Karte hängt an PC8-12,PD2 und der GPIO für SD-Present an PG2 
direkt auf 3,3V.

Der Schaltplan ab Seite 73 im PDF:
https://www.st.com/content/ccc/resource/technical/document/user_manual/group0/26/49/90/2e/33/0d/4a/da/DM00244518/files/DM00244518.pdf/jcr:content/translations/en.DM00244518.pdf

Was aber nicht zu der 3,3 V Theorie passt, ist das der stlink schon 
abschmiert bevor f_mount überhaupt aufgerufen wird. Wie schon gesagt, 
ist f_mount auskommentiert läuft alles auch mit angeschlossener SD-Card. 
Mit f_mount kommt aber nicht mal die boot message auf der UART die 
wesentlich weiter vorne kommt.

Das der stlink abschmiert sieht man am output vom 2. Flashversuch den 
ich vorhin angehängt habe.

1. Flashversuch erfolgreich

2019-08-03T22:52:50 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
size: 32768
size: 17280
2019-08-03T22:52:52 INFO common.c: Starting verification of write complete
2019-08-03T22:52:53 INFO common.c: Flash written and verified! jolly good!

2. Flashversuch schlägt fehl

2019-08-03T22:53:13 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
2019-08-03T22:53:16 ERROR flash_loader.c: flash loader run error
2019-08-03T22:53:16 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1
stlink_fwrite_flash() == -1

Grüße Heiko

[Heiko J. (heiko_j)]

So, anbei die 2 "nm -Snv" der elf files. Einmal mit f_mount (crasht), 
einmal f_mount (läuft) auskommentiert.

Gruß Heiko

[Jim M. (turboj)]

Heiko J. schrieb:
> Was aber nicht zu der 3,3 V Theorie passt, ist das der stlink schon
> abschmiert bevor f_mount überhaupt aufgerufen wird.

Das würde ich mal mit einem Oszi prüfen. Es gibt nämlich nicht viele 
andere Gründe warum das tty weg gehen sollte. Was sagt eigentlich dmesg 
dazu? USB Resets schreibt der Kernel aus.

Außerdem würde ich den delay vom Reset bis f_mount() versuchsweise noch 
weiter vergrößern, auf so 5-10 Sekunden.
Nach dem Flashen wird oft der µC erstmal gestartet und dann nochmal 
resettet (je nach Config von Flasher, Debugger etc). Die 500ms könnten 
noch zuwenig sein.

Ich mache mir beim µC Start gerne mal eine LED Blinksequenz rein.

[Heiko J. (heiko_j)]

So .... kleines Update. Es sieht nur so aus als ob das tty weg fliegt, 
weil ich ja zum wiederbeleben den stlink ab- und wieder anstecken muss 
...
Der stlink selbst ist noch da, aber es gibt wohl einen Bug im st-flash, 
dass  das st-flash utility das flashen nur beim ersten mal immer richtig 
macht. (https://github.com/texane/stlink/issues/607).

Ändert aber trotzdem nichts daran das der Code das target zum abkacken 
bringt.

[Heiko J. (heiko_j)]

Jim M. schrieb:
> Das würde ich mal mit einem Oszi prüfen. Es gibt nämlich nicht viele
> andere Gründe warum das tty weg gehen sollte. Was sagt eigentlich dmesg
> dazu? USB Resets schreibt der Kernel aus.
Oszi hab ich ausprobiert. Sieht gut aus. Saubere 3,3V. Ich glaub das tty 
fliegt aber nicht wirklich weg. Sondern ich hab mir da selbst ein Bein 
gestellt, weil nur das ab/an-stecken den st-link wieder zum laufen 
bringt.
Gibt wohl einen Bug im st-flash der mich da trifft wenn das target hängt 
...(https://github.com/texane/stlink/issues/607)

[1326538.580832] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)
[1326538.580980] sd 6:0:0:0: [sdd] Write Protect is off
[1326538.580983] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00
[1326538.581128] sd 6:0:0:0: [sdd] No Caching mode page found
[1326538.581131] sd 6:0:0:0: [sdd] Assuming drive cache: write through
[1326538.598915] sd 6:0:0:0: [sdd] Attached SCSI removable disk
[1328066.880936] usb 1-4.3.1: USB disconnect, device number 23
[1328069.149478] usb 1-4.3.1: new full-speed USB device number 24 using xhci_hcd
[1328069.250946] usb 1-4.3.1: New USB device found, idVendor=0483, idProduct=374b
[1328069.250951] usb 1-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1328069.250954] usb 1-4.3.1: Product: STM32 STLink
[1328069.250957] usb 1-4.3.1: Manufacturer: STMicroelectronics
[1328069.250959] usb 1-4.3.1: SerialNumber: 066EFF565154667867192255
[1328069.305263] usb-storage 1-4.3.1:1.1: USB Mass Storage device detected
[1328069.305329] scsi host6: usb-storage 1-4.3.1:1.1
[1328069.305690] cdc_acm 1-4.3.1:1.2: ttyACM0: USB ACM device
[1328070.326238] scsi 6:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2
[1328070.327043] sd 6:0:0:0: Attached scsi generic sg4 type 0
[1328070.327207] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)
[1328070.327390] sd 6:0:0:0: [sdd] Write Protect is off
[1328070.327395] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00
[1328070.327573] sd 6:0:0:0: [sdd] No Caching mode page found
[1328070.327581] sd 6:0:0:0: [sdd] Assuming drive cache: write through
[1328070.345665] sd 6:0:0:0: [sdd] Attached SCSI removable disk
[1352245.600209] usb 1-4.3.1: USB disconnect, device number 24
[1352245.662533] FAT-fs (sdd): unable to read boot sector to mark fs as dirty
[1352248.382240] usb 1-4.3.1: new full-speed USB device number 25 using xhci_hcd
[1352248.483857] usb 1-4.3.1: New USB device found, idVendor=0483, idProduct=374b
[1352248.483861] usb 1-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1352248.483864] usb 1-4.3.1: Product: STM32 STLink
[1352248.483866] usb 1-4.3.1: Manufacturer: STMicroelectronics
[1352248.483868] usb 1-4.3.1: SerialNumber: 066EFF565154667867192255
[1352248.538428] usb-storage 1-4.3.1:1.1: USB Mass Storage device detected
[1352248.538546] scsi host6: usb-storage 1-4.3.1:1.1
[1352248.538855] cdc_acm 1-4.3.1:1.2: ttyACM0: USB ACM device
[1352249.570939] scsi 6:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2
[1352249.571886] sd 6:0:0:0: Attached scsi generic sg4 type 0
[1352249.572078] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)
[1352249.572255] sd 6:0:0:0: [sdd] Write Protect is off
[1352249.572259] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00
[1352249.572415] sd 6:0:0:0: [sdd] No Caching mode page found
[1352249.572420] sd 6:0:0:0: [sdd] Assuming drive cache: write through
[1352249.590340] sd 6:0:0:0: [sdd] Attached SCSI removable disk

>
> Außerdem würde ich den delay vom Reset bis f_mount() versuchsweise noch
> weiter vergrößern, auf so 5-10 Sekunden.
> Nach dem Flashen wird oft der µC erstmal gestartet und dann nochmal
> resettet (je nach Config von Flasher, Debugger etc). Die 500ms könnten
> noch zuwenig sein.
>
> Ich mache mir beim µC Start gerne mal eine LED Blinksequenz rein.

Hab ich beides schon gemacht. Resultat das selbe. Der Code läuft nicht 
mal an.

Gruß Heiko

[MaWin (Gast)]

Heiko J. schrieb:
> Was für eine hilfreiche Antwort !
> Danke sehr !

Gerne, ich hol mir jetzt einen runter...

[Heiko J. (heiko_j)]

So ... weiteres update. Der Code läuft prinzipiel an, aber kackt bereits 
im  "MX_USB_DEVICE_Init();" Ganz vorne ab ... Also im vom STM32CubeMX 
generierten Code, weit bevor ich was verbrochen hab. Wenigstens komme 
ich der Sache jetzt mal näher

[Heiko J. (heiko_j)]

Je mehr Debug code ich rein mache desto weiter vorne kackt alles ab. 
Wahrscheinlich wird der Stack überschrieben vermute ich mal.

Ich denke damit ist das Problem wohl zumindest mal eingegrenzt.

[Heiko J. (heiko_j)]

Hab jetzt FATFS fs anstatt im Task als Variable anzulegen als Variable 
im Modul angelegt damit es auf dem Heap anstatt auf dem Stack landet und 
es funktioniert.

Fazit: Stack überschrieben und zusammen mit dem Bug im st-flash utility 
ziemlich lange rum gesucht .....

Gruß Heiko

[Junger Mann (Gast)]

Also so wie ich gesagt habe :-)

[Jim M. (turboj)]

Heiko J. schrieb:
> Fazit: Stack überschrieben und zusammen mit dem Bug im st-flash utility
> ziemlich lange rum gesucht .....

So ein Bug ist ja mal echt nervig. Hast Du JLink Debugger rumfliegen 
oder kannst Du die STLink umflashen?

Ich kenne bei meinen JLinks hier (auf verschiedenen Dev Boards) solche 
Probleme mit (USB-)Resets nicht.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Wenn du die Variable im Task angelegt hast musste die Stackgröße des 
Tasks anpassen.
Daher hats nix gebracht den globalen Stack zu vergrößern.
Guck mal wo der Task initialisiert wird, da wird auch die Stackgröße 
definiert.

Die Standardstackgröße eines Task ohne manuelle Vergrößerung ist recht 
klein.
Nicht, dass dieses Problem nochmal vorkommt.

Ansonsten kann man zum entwickeln bei FreeRTOS einen kleinen 
Stackchecker aktivieren der per MagicWords guckt ob ein Stack zu groß 
wird.