stm32 FatFS stranges Problem

Was für eine hilfreiche Antwort !
Danke sehr !

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

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

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.

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

1

2019-08-03T22:52:50 INFO flash_loader.c: Successfully loaded flash loader in sram

2

enabling 32-bit flash writes

3

size: 32768

4

size: 32768

5

size: 32768

6

size: 17280

7

2019-08-03T22:52:52 INFO common.c: Starting verification of write complete

8

2019-08-03T22:52:53 INFO common.c: Flash written and verified! jolly good!

2. Flashversuch schlägt fehl

1

2019-08-03T22:53:13 INFO flash_loader.c: Successfully loaded flash loader in sram

2

enabling 32-bit flash writes

3

size: 32768

4

2019-08-03T22:53:16 ERROR flash_loader.c: flash loader run error

5

2019-08-03T22:53:16 ERROR common.c: stlink_flash_loader_run(0x8000000) failed! == -1

6

stlink_fwrite_flash() == -1

Grüße Heiko

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

Gruß Heiko

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.

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.

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)

1

[1326538.580832] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)

2

[1326538.580980] sd 6:0:0:0: [sdd] Write Protect is off

3

[1326538.580983] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00

4

[1326538.581128] sd 6:0:0:0: [sdd] No Caching mode page found

5

[1326538.581131] sd 6:0:0:0: [sdd] Assuming drive cache: write through

6

[1326538.598915] sd 6:0:0:0: [sdd] Attached SCSI removable disk

7

[1328066.880936] usb 1-4.3.1: USB disconnect, device number 23

8

[1328069.149478] usb 1-4.3.1: new full-speed USB device number 24 using xhci_hcd

9

[1328069.250946] usb 1-4.3.1: New USB device found, idVendor=0483, idProduct=374b

10

[1328069.250951] usb 1-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

11

[1328069.250954] usb 1-4.3.1: Product: STM32 STLink

12

[1328069.250957] usb 1-4.3.1: Manufacturer: STMicroelectronics

13

[1328069.250959] usb 1-4.3.1: SerialNumber: 066EFF565154667867192255

14

[1328069.305263] usb-storage 1-4.3.1:1.1: USB Mass Storage device detected

15

[1328069.305329] scsi host6: usb-storage 1-4.3.1:1.1

16

[1328069.305690] cdc_acm 1-4.3.1:1.2: ttyACM0: USB ACM device

17

[1328070.326238] scsi 6:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2

18

[1328070.327043] sd 6:0:0:0: Attached scsi generic sg4 type 0

19

[1328070.327207] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)

20

[1328070.327390] sd 6:0:0:0: [sdd] Write Protect is off

21

[1328070.327395] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00

22

[1328070.327573] sd 6:0:0:0: [sdd] No Caching mode page found

23

[1328070.327581] sd 6:0:0:0: [sdd] Assuming drive cache: write through

24

[1328070.345665] sd 6:0:0:0: [sdd] Attached SCSI removable disk

25

[1352245.600209] usb 1-4.3.1: USB disconnect, device number 24

26

[1352245.662533] FAT-fs (sdd): unable to read boot sector to mark fs as dirty

27

[1352248.382240] usb 1-4.3.1: new full-speed USB device number 25 using xhci_hcd

28

[1352248.483857] usb 1-4.3.1: New USB device found, idVendor=0483, idProduct=374b

29

[1352248.483861] usb 1-4.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3

30

[1352248.483864] usb 1-4.3.1: Product: STM32 STLink

31

[1352248.483866] usb 1-4.3.1: Manufacturer: STMicroelectronics

32

[1352248.483868] usb 1-4.3.1: SerialNumber: 066EFF565154667867192255

33

[1352248.538428] usb-storage 1-4.3.1:1.1: USB Mass Storage device detected

34

[1352248.538546] scsi host6: usb-storage 1-4.3.1:1.1

35

[1352248.538855] cdc_acm 1-4.3.1:1.2: ttyACM0: USB ACM device

36

[1352249.570939] scsi 6:0:0:0: Direct-Access     MBED     microcontroller  1.0  PQ: 0 ANSI: 2

37

[1352249.571886] sd 6:0:0:0: Attached scsi generic sg4 type 0

38

[1352249.572078] sd 6:0:0:0: [sdd] 4168 512-byte logical blocks: (2.13 MB/2.04 MiB)

39

[1352249.572255] sd 6:0:0:0: [sdd] Write Protect is off

40

[1352249.572259] sd 6:0:0:0: [sdd] Mode Sense: 03 00 00 00

41

[1352249.572415] sd 6:0:0:0: [sdd] No Caching mode page found

42

[1352249.572420] sd 6:0:0:0: [sdd] Assuming drive cache: write through

43

[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

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

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.

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

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.

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.