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

STM32OpenOCD Gast #3140451 
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:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Langsamer Modus Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Melden Danke
Jim M. #3140489 
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.
Antwort Zitieren Bearbeiten Löschen Melden Danke
STM32OpenOCD Gast #3140926 
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!
Antwort Zitieren Bearbeiten Löschen Melden Danke
STM32OpenOCD Gast #3140927 
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 Zitieren Bearbeiten Löschen Melden Danke
STM32OpenOCD Gast #3140929 
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.
Antwort Zitieren Bearbeiten Löschen Melden Danke
Thread beobachten

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 13 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.