GDB hängt sich auf - Ignoring packet error, continuing.

[Daniel F. (franken_3)]

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

[GDB hängt sich auf (Gast)]

>Remote debugging using localhost:4242

Offensichtlich OpenOCD als gdbserver.

Was sagt Dein OpenOCD Debug log?

[Daniel Eck (Gast)]

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

[At 9 (Gast)]

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.

[Daniel F. (franken_3)]

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.