arm-none-eabi-gdb bei eclipse-Toolchain crasht

[STM32OpenOCD (Gast)]

Bei einem Projekt funktioniert das Debuggen mit OpenOCD wunderbar, beim 
anderen aber gar nicht:
Nach dem Start verbindet er sich ganz normal mit OpenOCD, dann dauert es 
ab dem Punkt "stack-info-depth" ziemlich lange, er macht aber noch 
weiter und öffnet manchmal auch schon die Debug-Perspective. Das 
seltsame ist, dass arm-none-eabi-gdb dabei ca. 2GB RAM reserviert und 
dann abstürtzt - weil er keinen RAM mehr reservieren kann...

This application has requested the Runtime to terminate it in an unusual 
way.
Please contact the application's support team for more information.
/scratch/jbrown/arm-eabi/obj/gdb-src-2012.09-63-arm-none-eabi-i686-mingw 
32/gdb/utils.c:1081:  internal-error: virtual memory exhausted: can't 
allocate 4072 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
468-gdb-exit

Hat irgendwer vielleicht eine Idee, woran das liegen könnte? OpenOCD hat 
mich schon fast in die Verzweiflung getrieben... und jetzt das nächste.
Danke!

[madeyemike (Gast)]

Das Problem ist mir auch schon untergekommen. Bei mir lags am leeren 
while(1). Scheint ein Problem im GCC oder GDB zu sein....

mfg madeyemike

[STM32OpenOCD (Gast)]

Danke für den Tip, hat bei mir leider nichts gebracht...
Die Dateien sind auch größenmäßig unauffällig...

[Jim M. (turboj)]

Ist das ein Cortex M3? Dann versuche es mal mit einer target.xml, siehe 
Beitrag "Re: arm-gdb backtrace funktioniert nicht vom hard fault handler"

Darin werden die Register definiert, und der GDB schaltet in dem -M 
Modus um, so dass er den Stack bei Exceptions korrekt darstellen kann.

Welche OpenOCD Version benutzt Du? Einige ältere verwendeten IIRC ein 
nicht kompatibles Format für die Register.

[STM32OpenOCD (Gast)]

Ja, ein STM32. Das würde mich verwirren, denn ein anderes Projekt 
funktioniert ja. Wo bekommt man besagte Datei her?
Ich benutze OpenOCD 0.6.1.

[STM32OpenOCD (Gast)]

Der Fehler leigt wohl darin, dass OpenOCD nicht die Dateien für STM32 
verwendet, sondern für ARM7. Nachdem ich alle Einstellungen vom anderen 
und diesem Projekt mehrfach verglichen habe und keinerlei Unterschiede 
feststellen konnte: Hat vielleicht jemand einen Tip, wie man OpenOCD 
mitteilt, dass man auch wirklich einen STM32 programmiert, obwohl es den 
Controller richtig erkennt und auch die Dateien für STM32 als Argument 
bekommt?
Danke schonmal!

[STM32OpenOCD (Gast)]

Es hat auch nichts mit den Projekteinstellungen zu tun, wie sich 
herausstellt. Kopiere ich den Source ins andere Projekt zeigt es 
dasselbe verhalten...
Echt super, bevor man den µC debuggt sollte man erst einmal den Debugger 
debuggen.

[STM32OpenOCD (Gast)]

Ich habe den Fehler gefunden - sobald eine Datei mit dem Namen 
syscalls.c existiert spinnt er. Dann wählt OpenOCD einfach einen anderen 
Controller und arm-none-eabi-gdb sammelt Müll.