Hallo, seit kurzem kann ich keine Programme mehr auf meinen STM32F4 laden, der Debbuger hängt sich immer mit der Meldung Remote debugging using localhost:4242 0x000000000x00000000 in ?? () Connected Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Debugger finished with status 1 Ich habe den GDB dann von Hand abgebrochen. Weis jemand was das sein könnte? Bis vor einer Stunde ging noch alles wie gewohnt und auf einmal nicht mehr. Habe den PC schon mehrmals neu gestartet und auch andere Projekte versucht. Leider kein Erfolg? Ist etwa mein yC im Eimer :/ Danke Hoffe ihr könnt mir helfen. Wäre schade habe das Gerät erst seit einigen Tagen?? Danke
Gast
#3924713
>Remote debugging using localhost:4242
Offensichtlich OpenOCD als gdbserver.
Was sagt Dein OpenOCD Debug log?
Gast
#3925737
Hi, habe mir heute STMLink Utility V3.5 von ST herunter geladen. Dort gibt es die Option "Erase Flash". Danach konnte ich den yC wieder bespielen, allerdings nur einmal. Nachdem ich in wieder gelöscht hatte und ein anderes Projekt genommen habe, ging alles wie gewohnt. Irgendwas habe ich in dem Projekt angestellt, als ich die main auf mehrere Datein aufgeteilt habe, dass der yC nicht verträgt. Werde jetzt im Laufe der Woche mal ein Modul nach dem anderen aus dem Projekt entfernen, vielleicht finde ich die Ursache auf diese Weise. Eventuell darf ich die Interrupt-Handler nicht in eine eigene Datei auslagern oder aber die globalen Variablen in der glabe.c /.h machen Ärger?? Werde es hier schreiben wenn ich die Urasache gefunden habe. PS: In dem Beitrag oben wurde nach einem log-File gefragt? Wo finde ich das denn? Danke
Gast
#3926402
Das ist ein Problem zwischen gdb und Deinem gdbserver. Deine Spekulationen haben mit der wahren Ursache nicht direkt zu tun. Kann es sein, dass Du in deinem Programm mit den clocks oder den GPIOs rumspielst? Manche davon, sind WIMRE, mit dem JTAG/SWD gemultiplext. Vielleicht wird dadurch ein Problem in dem st-util getriggert, das sich in einer fehlkommunikation zum gdb äussert. Eventuell mal OpenOCD alternativ ausprobieren. Oder (gdb) target extended-remote :4242 statt (gdb) target remote :4242 >Offensichtlich OpenOCD als gdbserver. Wohl eher das st-util von texane? Der benutzt Port 4242 als Default.
So, habe die Ursache für dieses merkwürdige Problem gefunden. Ich habe die Pins A14 und A15 als Input konfiguriert GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_DOWN; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN; Möglicherweise sind diese PINS nicht als Eingaenge nutzbar, das weis ich nicht genau leider. Aber sowie ich diese Initalisierung auskommentiert habe, geht das Debugen wieder wie gewohnt.