Hi, all.
I just found a bug in GDB which destabilized serial port debugging.
The bug causes gdb to sometimes communicate improperly with pdebug over
serial ports. This is why we see it working sometimes, and then not working.
The bug does not appear to affect TCP/IP.
Please let me know.
Regards,
GP
I don’t think I’m using the same port. I’m using /dev/ser2
as the console and /dev/ser1 for pdebug…
But I’ll do an extra check on that, just to be absolutely sure. > 
-Arve
Graeme Peterson wrote:
Arve Slenes <> arve@datarespons.no> > wrote:
Sorry about the delay, but I’ve been tied up with a few other things…
Anyway, pdebug says:
This version of pdebug was built on Jun 22 2001.
ProtoVer 0.1
I’m running a DigitalLogic 66Mhz (can increase speed to 133Mhz)
target and a IBM PC with some Pentium MMX processor as host.
Not sure which speed, but sertainly not the fastest in the world.
GDB says it is gdb 5.0 when it starts up. ‘which -l gdb’ returns
‘/usr/bin/gdb’
Just tried ‘gdb -b 38400’ and ‘PDEBUG_DEBUG=1 pdebug /dev/ser1,38400’.
Same response as before mentioned.
Hey, Arve. Just curious, but are you trying to double up /dev/ser1 on the
target? Is pdebug trying to share with the console? If so, this is probably
the problem. Give pdebug a dedicated serial port.
Let me know.
GP
-Arve
Graeme Peterson wrote:
Arve Slenes <> arve@datarespons.no> > wrote:
Ok, so it can work. This is good news. Have you tried a different
serial cable? When you first start pdebug, what date does it say
it was built on, and what Protocol Version is it using?
eg:
This version of pdebug was built on Jun 3 2001.
ProtoVer 0.1
What speed and OS are your host and your target? ie: PIII-850 ntox86 targetting
a 20 MHz ntoarm board?
What about gdb? which -l gdb ? Is it gdb5 ?
Thanks.
OK!
It miraculously worked once… So it’s a bit unstable…
After miraculously getting it to work straigth away, running gdb and pdebug as
they talked perfectly over the 38400 bps serial line, I closed down the programs to
do some other stuff. Then, when trying to connect again, it did not work… The old
problems where back.
Restarting the PC and the target, or slaying the devc-ser8250, did not seem to help.
gdb with the same messages as before and pdebug gave the following text with
PDEBUG_DEBUG=1 set and ‘pdebug /dev/ser1,38400’ running:
Com port /dev/ser1 initialized OK
Target initialized OK
pdebug initialized
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetConnect: major=0 minor=1
ResponseOKStatus status=1056
Host resent message with id 0 (0x0). Resending response.
Host resent message with id 0 (0x0). Resending response.
TargetDisconnect
TargetEnv: Clearing Environment
TargetEnv: Clearing Arguments
TargetDetach pid=0
Response OK
Host resent message with id 1 (0x1). Resending response.
Host resent message with id 1 (0x1). Resending response.
Graeme Peterson wrote:
Arve Slenes <> arve@datarespons.no> > wrote:
Hi. What are your host and target machines? To eliminate variables,
please try using baudrates of 38400 on both machines.
Before running pdebug, export PDEBUG_DEBUG=1, which will provide the
maximum debug output, and then please post the output here. Also, be
aware that pdebug will set the baudrate, so you must give it the right
speed on the command line. The default is 57600, so if you run:
stty 38400 < /dev/serN
pdebug &
it will reset the serial port to 57600.
Another thing that has helped me on occasion is to slay and restart
devc-ser8250: (on x86)
slay devc-ser8250
devc-ser8250 &
Let me know.
GP
Hi Colin!
Could you perhaps post a pair of stty settings that DO work…
Then I can try those. >
-Arve
Colin Burgess wrote:
Can you post the output of stty -a < /dev/ser for BOTH serial ports
when gdb and pdebug are trying to connect?
Arve Slenes <> arve@datarespons.no> > wrote:
Status:
I can receive stuff both ways with ‘cat < /dev/serX’ when using ‘qtalk’, but
not when using
‘cat > /dev/serX’. That is ‘cat > /dev/serX’ does not seem to work, ‘qtalk’
works.
Are there any special serial settings I need for cat perhaps??
Still no contact with pdebug other than pdebug saying
‘Host resent message with id 0 (0x0). Resending response.’
I’m using pdebug -v
-Arve
Colin Burgess wrote:
A few things to try…
- check that you can send data via the ‘cat’ command both ways over
the null modem
eg:
host$ cat > /dev/ser1
fjdslkfjdlksjfkldsjflkdsjflds
target$ cat < /dev/ser1
fjdslkfjdlksjfkldsjflkdsjflds
- check that you are starting pdebug with the right baudrate, I believe
the default is 57600
eg:
target$ pdebug /dev/ser1,115200
- if you have another port to the machine, start pdebug in verbose mode
eg
target$ PDEBUG_DEBUG=1 pdebug /dev/ser1,115200
Arve Slenes <> arve@datarespons.no> > wrote:
When trying to connect to the remote ‘pdebug’ I get the following:
START
(gdb) target qnx /dev/ser1
Remote debugging using /dev/ser1
Timeout in mid-packet, retrying
MsgNak received - resending
Timeout in mid-packet, retrying
MsgNak received - resending
Timeout in mid-packet, retrying
MsgNak received - resending
Remote exhausted 3 retries.
Couldn’t establish connection to remote target
Connection failed: 5.
Timeout in mid-packet, retrying
MsgNak received - resending
Timeout in mid-packet, retrying
MsgNak received - resending
Timeout in mid-packet, retrying
MsgNak received - resending
Remote exhausted 3 retries.
END
Yes, I have tried to extend the timeout to as much as 120 sec.
Yes, both serial ports are set to the same baudrate and comms. settings.
Yes, a nullmodem cable is used.
Yes, something happens on the target side
and that is (after a successful pdebug init) when i call (gdb) target
qnx /dev/ser1:
Host resent message with id 0 (0x0). Resending response.
Host resent message with id 0 (0x0). Resending response.
Host resent message with id 1 (0x1). Resending response.
Host resent message with id 1 (0x1). Resending response.
Any sugestions of what might be wrong anyone?
Regards
-Arve
–
cburgess@qnx.com
–
cburgess@qnx.com