W dniu 2013-01-25 07:13, Chris Johns pisze: > Freddie Chopin wrote: >> >> You have to narrow down the commands you have to execute via telnet to >> make GDB work and then you should add them to the -c "init; ..." switch. >> > > I suspect the issue is an initialization time verses the gdb remote > protocol timeout. This is the TCP trace as seen by gdb with the remote > protocol debug enabled ... > > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack > Packet received: > PacketSize=3fff;qXfer:memory-map:read-;qXfer:features:read-;QStartNoAckMode+ > > Packet qSupported (supported-packets) is supported > Sending packet: $QStartNoAckMode#b0...Ack > Packet received: OK > Sending packet: $!#21...Packet received: OK > Sending packet: $Hg0#df...Packet received: OK > Sending packet: $?#3f...Packet received: S02 > Sending packet: $Hc-1#09...Packet received: OK > Sending packet: $qC#b4...Packet received: QC0 > Sending packet: $qAttached#8f...Packet received: 1 > > while the pipe version is .... > > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a... > Sending packet: $qSupported:multiprocess+;qRelocInsn+#2a...Ack > Packet received: > PacketSize=3fff;qXfer:memory-map:read-;qXfer:features:read-;QStartNoAckMode+ > > Packet qSupported (supported-packets) is supported > Sending packet: $QStartNoAckMode#b0...Ack > Packet received: > PacketSize=3fff;qXfer:memory-map:read-;qXfer:features:read-;QStartNoAckMode+ > > Sending packet: $!#21...Packet received: > PacketSize=3fff;qXfer:memory-map:read-;qXfer:features:read-;QStartNoAckMode+ > > Sending packet: $Hg0#df...Packet received: OK > Sending packet: $?#3f...Packet received: OK > Sending packet: $Hc-1#09...Packet received: OK > Sending packet: $qC#b4...Packet received: S02 > Sending packet: $qAttached#8f...Packet received: OK > Packet qAttached (query-attached) is supported > Packet received: QC0 > warning: Invalid remote reply: QC0 > > Note the '$?#3f' TCP response is 'S02' which is ok while the PIPE > response is 'OK' and 'S02' is returned for '$qC#b4' and finally the > protocol falls over with the 'QC0' response that is out of sequence. It > would seem a timeout repeats the initial command ($qSupported:..) and > they are queued on the stdin pipe input then processed by the server > how-ever gdb has moved on. > > I could use the server mode as this works and ignore the issue or a hack > of setting the gdb remote timeout to be longer than the start up time > (yuck). I suppose the correct fix is to have openocd flush the input > buffer of the pipe after the server connects, gdb will timeout and > repeat the command and both sides would then be in sync. > > Chris
I've forwarded your message to -devel group, maybe there someone will be able to solve this issue. I remember there was some -pipe related patch recently... 4\/3!! ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
