Mam:

Zastrzeżona prototypowa płyta ARM (oparta na Cortex-M3) z systemem eCos OSPłyta ma zaprogramowany bootloader RedBootLinia szeregowa (RS-232)Debugger GDB dla ARM (arm-eabi-gdb)System operacyjny to Windows / Cygwin i / lub Linux (właściwie nie ma znaczenia)

Problem: Debugger GDB nie może połączyć się z celem przez linię szeregową.

Czego chcę: polega na wąchaniu pakietów zdalnego protokołu GDB w celu wykrycia, czy kod GDB na obiekcie docelowym jest żywy i działa.

Detale: RedBoot ma opcję przekazania kontroli celu do wbudowanego kodu GDB. Wiem, że RedBoot żyje, mogę się z nim połączyć i wysyłać polecenia przez linię szeregową.Podręcznik RedBoot mówi, że przełączenie na skrót GDB może być dokonane przez wpisanie symboli $ lub + (które są w rzeczywistości przedrostkami pakietów protokołu zdalnego GDB). Wydaje się działać, gdy wysyłam te symbole, terminal umiera. Ale nie jestem pewien, czy RedBoot został skompilowany z obsługą stubu GDB (nie pytaj mnie dlaczego :-)).

Następnie, gdy próbuję połączyć się z płytą za pomocą debugera GDB, otrzymuję następujący obraz (w systemie Windows):

(gdb) target remote COM3
Remote debugging using COM3
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...

Port jest poprawny, szybkość transmisji również. Właściwie to samo wyjście, które otrzymuję, gdy próbuję zrobić to samo z innym portem szeregowym, który nie jest połączony z niczym.

Co chcę wiedzieć, to czy skrót GDB wysyła coś, czy nie?

Intuicyjnie myślałem, że tak

set verbose on

pomogłoby, ale instrukcja GDB mówi, że ma bardzo ograniczony efekt, a moja sprawa jest poza tym.

Może być możliwe skompilowanie debuggera GDB z makro, które umożliwia rejestrowanie debugowania?