STM32 CubeIDE, Debuggen nicht mehr möglich

[Modell B. (modell_b)]

Hallo Zusammen,
ich arbeite seit längerem an einem Projekt mit einem STM32f746g_Disco.
Das Projekt läuft mit FreeRTOS, und hat bisher keine Probleme gemacht.

Jetzt ist es aber seit ein paar Wochen so, dass ich nicht mehr debuggen 
kann. Die HEX Datei kann ich problemlos über "RUN" oder den 
STM32CubeProgrammer flashen, und dann funktioniert auch alles, aber wenn 
ich den Debug modus verwende, dann sehe ich nur static noise auf dem 
Display. Im Programmcode springt die Zeile sofort zum HardFault_Handler.

Im STM Forum habe ich auch schon nachgefragt, da kommen aber nur sehr 
schleppend Antworten. Daher hoffe ich, dass mir hier besser geholfen 
wird.
Zur Vollständigkeit, hier der Thread im STM Forum:

https://community.st.com/t5/stm32cubeide-mcu/stm32cube-ide-quot-run-quot-works-quot-debug-quot-doesn-t/td-p/583077

Ich kann so schon an dem Programm weiterarbeiten, aber komplett ohne 
Debug funktion ist es schon seeehr aufwändig...

Danke schonmal für eure Vorschläge!

[Stefan F. (Gast)]

Debugge ein anderes möglichst einfaches Programm, z.B. einen LED 
Blinker.

Wenn das geht, liegt es wahrscheinlich an deinem eigenen Programmcode. 
Im Debug Modus wird normalerweise eine andere Optimierungsstufe 
verwendet, Sleep Modi sind nur eingeschränkt verwendbar und viele 
Timings sind ganz anders.

[J. S. (jojos)]

das hört sich aber schon nach Fehler im eigenen Code an. Mal Tasks nicht 
starten um den Fehler einzugrenzen?

[Modell B. (modell_b)]

Okay, danke für die Hinweise.

Ich wusste nicht dass sich das System andersartig verhält beim debuggen, 
und hab deshalb bis jetzt einen Fehler im eigenen Code ausgeschlossen.

Aber ich teste mal und lass diverse Tasks nicht starten.

Danke schonmal!

[Harry L. (mysth)]

Vor allem aber brauchen die Tasks beim Debuggen mehr Stack.
Darauf bin ich auch schon häufiger hereingefallen. Das führt dann auch 
regelmässig zu HardFaults.

[Moot S. (mootseeker)]

Ein tipp ist immer:
Stack und Heap vergrössern oder von Begin an sehr gross wählen. Später 
kannst den immer wieder kleiner machen.

Meistens haben zu kleine Speicher komische verhalten beim debuggen.

[Stefan F. (Gast)]

Moot S. schrieb:
> Ein tipp ist immer:
> Stack und Heap vergrössern oder von Begin an sehr gross wählen. Später
> kannst den immer wieder kleiner machen.

Bei meinen Projekten teilen sich Stack und Heap initial per default den 
gesamten verfügbaren RAM.

Ist das bei Cube Projekten anders?

[Harry L. (mysth)]

Stefan F. schrieb:
> Ist das bei Cube Projekten anders?

Das hat nichts mit Cube zu tun, sondern mit FreeRTOS.
Da solltest du dir das Speicherhandling wohl nochmal genauer anschauen!

[Stefan F. (Gast)]

Logisch, ein OS muss den Stack begrenzen. Daran hatte ich vorhin nicht 
gedacht.

[Guido K. (Firma: Code Mercenaries GmbH) (thebug)]

Also ein beliebter Fehler ist es beim Initialisieren der Portpins 
einfach die Debug-Pins zu überschreiben.