Merkwürdiges Verhalten von Code im Debugger.

Hans-Georg L. #8021848
Lesenswert?
• ▲
▼

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.

Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
N. M. #8021883
Lesenswert?
• ▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Nick #8021904
Lesenswert?
• ▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Hans-Georg L. #8021935
Lesenswert?
• ▲
▼

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.

Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren