Re: [Openocd-development] Debug in RAM error with IAR EWARM thru GDB since svn920(arm7/9 breakpoint cleanup)

[Duane E. <op...@du...>]

There are 2 things in the attached patch that should help determine what
is going wrong.

(A) IAR has a problem with 'O' packets larger then 99 bytes
new GDB command to help work around that, see below.

(B) In the "arm7_9" debug section, I added some LOG_DEBUG() messages
It seems there was little to *NONE* in that section of code.
Hence, it is very hard to trace problems.
See attached patch.

There is no reason the attached patch should not be committed.

--Duane.

=========================================

simony> IAR Embeded Workbench for ARM 5.11 doesn't have GDB console output.

I have this initial problem:

IAR kick start (32k version) chokes on large O packets.

I have a fix [see attached patch]

In this new patch, There is a new command:

> gdb configure -max-O-packet 0

Above is -max-(letter-O)-packet, not '-max-(number-ZERO)-packet.

The value 0 (zero) - disables all O (letter Oh) packets.
Default is now '256'

They seem to have a *STUPID* limit of exactly 99 bytes.
This works:
> gdb configure -max-O-packet 99
This fails
> gdb configure -max-O-packet 100

How much you wanna bet somebody @ IAR hard coded 100 somewhere?

======================================
Continuing.... with your original problem.

>> Error: unknown character 0x24 in reply, dropping connection
>> Warning:ignoring character 0x6d
>> Warning:ignoring character 0x31
>> Warning:ignoring character 0x2c
>> Warning:ignoring character 0x31
>> Warning:ignoring character 0x23
>> Warning:ignoring character 0x66
>> Warning:ignoring character 0x62

That translates to: $m1,1#fa

Which means: Read @ address 1, for 1 byte.

Openocd should not have a problem with that command.

However, I can't tell which of the two locations in 'gdb_server.c' this
is coming from. There are two identical error messages :-(

[NOT any more, my attached patch changes that]

I cannot get my instance to fail like you are having it fail. Perhaps it
is something specific to your code, or maybe your target.

Anyway - I suspect - I cannot confirm - that in this exactly place, IAR
has sent a 'm' packet. And OpenOCD is not expecting one... it is
expecting an ACK or NAK only.

My attached patch then tries to "unget" the 0x24 ($) start of packet and
assumes the packet waiting for the ACK is good, and does an "unget" so
the main packet decoder can find the new packet. (The other 'ignoring'
messages are coming from the main packet decoder)

I suspect IAR - gets no reply and dies a horrible death.

======================================
You are talking about BREAKPOINTS and STEPPING - etc.

I don't have an NXP LPC chip, I have atmel stuff.
I don't have problems you are having.

But - perhaps the additional log messages [in the patch] will help
narrow the problem.

======================================
**END**
======================================