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

Gast #3140451
Lesenswert?

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!
Angehängte Dateien:
#3140489
Lesenswert?

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.
Gast #3140926
Lesenswert?

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!
Gast #3140927
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren