Merkwürdiges Verhalten von Code im Debugger.

[Hans-Georg L. (h-g-l)]

Ich habe da ein kleines Problemchen ;-)

Ich habe SDCard mit FatFs auf einem H743 problemlos laufen.
Jetzt habe ich den Code auf eine H750 portiert und er läuft nicht wie er 
soll. Der H750 ist identisch mit dem H743 hat nur weniger Flash.

Auf den Bildern sieht man das der Code direkt von irgendwoher zu einem 
HAL_ERROR (zeile 487) springt ohne das if und die sdmmc_clock abfrage 
vorher auszuführen.
Die beiden breakpoints in Zeile 482 und 483 werden nicht ausgeführt.
sdmmc_clock ist nicht null und auf dem 2. Bild sieht man das Zeile 485 
und 486 auch nicht ausgeführt wurden sonst müssten state und errorcode 
in der Struktur hsd andere Werte haben.

Der Code wurde mit dem gleichen Compiler und den gleichen Optionen 
erstellt aber der fehlerhafte Code mit der neuesten Version von CubeMX 
erzeugt.

Hat jemand eine Idee wie so etwas passieren kann ?

Es ist nur noch ein USB HOST CDC(VCP) in dem fehlerhaften Code sonst 
nichts.

[Norbert (der_norbert)]

Hans-Georg L. schrieb:
> Auf den Bildern sieht man das der Code direkt von irgendwoher zu einem
> HAL_ERROR (zeile 487) springt ohne das if und die sdmmc_clock abfrage
> vorher auszuführen.

Komisches Verhalten: oftmals wenn Optimierung eingeschaltet.

[Harry L. (mysth)]

Ist da freeRTOS im Spiel?

Falls ja, vergrösser mal den Stack für den fraglichen Task.

[Hans-Georg L. (h-g-l)]

Harry L. schrieb:
> Ist da freeRTOS im Spiel?
>
> Falls ja, vergrösser mal den Stack für den fraglichen Task.

Nein kein freeRtos und die Schleife wird vorher auch 2 mal richtig 
durchlaufen ...

[N. M. (mani)]

Norbert schrieb:
> Komisches Verhalten: oftmals wenn Optimierung eingeschaltet.

Wäre auch meine Vermutung.

Schreib Mal folgendes eine Zeile vor der Funktion:

__attribute__((optimize("O0")))

übersetze dann nochmal und Versuch es nochmal mit dem debuggen.

[Hans-Georg L. (h-g-l)]

N. M. schrieb:
> Norbert schrieb:
>> Komisches Verhalten: oftmals wenn Optimierung eingeschaltet.
>
> Wäre auch meine Vermutung.
>
> Schreib Mal folgendes eine Zeile vor der Funktion:
>

> __attribute__((optimize("O0")))
>

>
> übersetze dann nochmal und Versuch es nochmal mit dem debuggen.

landet trotzdem im error handler ...
ich schlaf mal eine Nacht besser darüber ;-)

[Hans-Georg L. (h-g-l)]

Das ist alles HAL code und nicht von mir, warum sollte der Compiler es 
verschieden optimieren ?

[N. M. (mani)]

Hans-Georg L. schrieb:
> Das ist alles HAL code und nicht von mir, warum sollte der
> Compiler es verschieden optimieren ?

Es geht ja eher darum ob du WIRKLICH an dieser Stelle im Breakpoint 
bist.
Beim deguggen passiert es leicht dass man wild in der Gegend rum 
springt. Vorwärts, rückwärts, 5 Mal an die gleiche Stelle. Was aber 
alles nur so aussieht und der Optimierung geschuldet ist.

Deshalb empfiehlt es sich oft die Optimierung komplett auszuschalten 
wenn man deguggen möchte. Oder wenn das nicht geht (z.B. zu wenig 
Speicher) eben die Optimierung File- oder Funktionsweise auszuschalten.

[N. M. (mani)]

Hans-Georg L. schrieb:
> landet trotzdem im error handler ...
> ich schlaf mal eine Nacht besser darüber ;-)

Na dann musst du halt klären warum sdmmc_clk bei dem Controller 0 ist.

[Nick (b620ys)]

Hans-Georg L. schrieb:
> Das ist alles HAL code und nicht von mir

Im Kommentar darüber steht, dass clk > 400 kHz sein muss und dann wird 
eine Zeile drunter auf == 0 geprüft. ***PATSCH***

Ist denn das CLKFreq ein fester Wert oder ändert sich der Wert während 
der Laufzeit. Muss sich wohl ständig ändern, denn sdmmc_clk ist sogar 
volatile. Dann sollte er aber extern sein, denn wie soll er sich sonst 
ändern können?

Da scheint mir massiv was daneben gegangen zu sein.

[Hans-Georg L. (h-g-l)]

Nick schrieb:
> Hans-Georg L. schrieb:
>> Das ist alles HAL code und nicht von mir
>
> Im Kommentar darüber steht, dass clk > 400 kHz sein muss und dann wird
> eine Zeile drunter auf == 0 geprüft. ***PATSCH***
>
> Ist denn das CLKFreq ein fester Wert oder ändert sich der Wert während
> der Laufzeit. Muss sich wohl ständig ändern, denn sdmmc_clk ist sogar
> volatile. Dann sollte er aber extern sein, denn wie soll er sich sonst
> ändern können?
>
> Da scheint mir massiv was daneben gegangen zu sein.

Das volatile habe ich reingebaut damit der nicht wegoptimiert wird und 
der Kommentar bezieht sich nicht auf sdmmc_clk sondern auf Init.ClockDiv 
der daraus berechnet wird.

Aber das Problem lag an einer anderen Stelle, der Debugger hat mich 
veräppelt.