Hello,

I am trying to develop the software for a new LPC2138 project with the
Yagarto toolchain setup: Eclipse (3.2.2), GCC, Zylin CDT, GDB, OpenOCD
(re141), parallel port JTAG cable from Olimex.
The PC is a rather new one with a Pentium D, OS is Windows XP Pro SP2.

After entering the debug perspective, I can start OpenOCD as external
tool without any problems. I can also enter debug mode and upload the
program to the target device (though sometimes Eclipse freezes during
"launching").

However, when I then start the application (by clicking on the
run/resume icon), OpenOCD terminates and Eclipse pops up this message:
"Execution is suspended because of an error", with details "Remote
Communication Error: Bad File Descriptor".

I inserted
jtag_nsrst_delay 100
jtag_ntrst_delay 100
into the OpenOCD configuration, but that didn't change anything. Also,
changing the JTAG speed parameter only slowed things down, without any
other effect.

I have logged debug information of OpenOCD, hoping they provide any
useful information (117 KB each):




The last lines always are:

Debug: embeddedice.c:314 embeddedice_write_reg(): 0: 0x00000000
Debug: target.c:464 target_call_event_callbacks(): target event 1
Debug: arm7_9_common.c:1478 arm7_9_resume(): target resumed
Debug: embeddedice.c:218 embeddedice_read_reg_w_check(): 1
Warning: jtag.c:1068 jtag_read_buffer(): value captured during scan
didn't pass the requested check: captured: 0x0f check_value: 0x01
check_mask: 0x0f
Error: arm7_9_common.c:612 arm7_9_poll(): JTAG queue failed while
reading EmbeddedICE status register

Can anyone help? This is really boring...

Thanks,
Tilmann Start a New Thread

--- In l..., I wrote:

> [...]
> However, when I then start the application (by clicking on the
> run/resume icon), OpenOCD terminates and Eclipse pops up this message:
> "Execution is suspended because of an error", with details "Remote
> Communication Error: Bad File Descriptor".

Addendum:
It seems that the application runs quite well though. However, I can't
do any debugging this way - and before starting OpenOCD for the next
time, I have to issue a hardware reset.

Tilmann Start a New Thread

Hello Tilmann,

does your application modify the PINSEL register that controls the JTAG lines,
or does your code trigger a reset, maybe via a watchdog timer?
Something seems to disable the JTAG port as soon as execution is resumed.

Regards,

Dominic

On Monday 07 May 2007 15:49:51 Tilmann Reh wrote:
> --- In l..., I wrote:
> > [...]
> > However, when I then start the application (by clicking on the
> > run/resume icon), OpenOCD terminates and Eclipse pops up this message:
> > "Execution is suspended because of an error", with details "Remote
> > Communication Error: Bad File Descriptor".
>
> Addendum:
> It seems that the application runs quite well though. However, I can't
> do any debugging this way - and before starting OpenOCD for the next
> time, I have to issue a hardware reset.
>
> Tilmann Start a New Thread

--- In l..., Dominic Rath wrote:
>
> Hello Tilmann,
>
> does your application modify the PINSEL register that controls the
JTAG lines,
> or does your code trigger a reset, maybe via a watchdog timer?
> Something seems to disable the JTAG port as soon as execution is
resumed.

Hello Dominic,

BINGO - and many thanks for your fast reply.

I had modified the port initialization, and overlooked the Debug bit
in PINSEL2... Sorry, that was rather stupid.

Now entering debug state works again, but the stability issues of
Eclipse/GDB are present again. Every few minutes, something crashes
(most of the time Eclipse becomes inoperable and does not react on
mouse clicks any more - or in a strange way). I think I should start a
new thread on this - but I don't know how to obtain detailed debug
information about this...

However, many thanks.
Tilmann Start a New Thread

Hello Tilmann,

On Monday 07 May 2007 17:26:40 Tilmann Reh wrote:
> --- In l..., Dominic Rath wrote:
> Hello Dominic,
>
> BINGO - and many thanks for your fast reply.
>
> I had modified the port initialization, and overlooked the Debug bit
> in PINSEL2... Sorry, that was rather stupid.
>
Great, glad you got it working.

> Now entering debug state works again, but the stability issues of
> Eclipse/GDB are present again. Every few minutes, something crashes
> (most of the time Eclipse becomes inoperable and does not react on
> mouse clicks any more - or in a strange way). I think I should start a
> new thread on this - but I don't know how to obtain detailed debug
> information about this...
>
Sorry, I don't think I can help you with this. I don't use Eclipse for
anything but editing the OpenOCD source code. I like its convenience features
(auto completion, navigating the source code etc.) but for debugging a plain
GDB is all I need.

One thing that affects all GDB based solutions (plain GDB, Insight, Eclipse)
is that GDB sometimes fails to decide whether a source line should be stepped
using a breakpoint or by stepping until the next sourceline is reached. This
problem for example causes a "next" on a source line containing an empty
for-loop (for (i = 0; i < DELAY; i++);) to be stepped using single assembly
steps. OpenOCD might be able to execute up to 5 steps per second (never
measured, just a guess), but stepping a delay loop that counts to millions is
going to take forever with this.
I work around this by placing a temporary breakpoint (thbreak
file.c:line-number) after the loop.
Real world code is hopefully rarely going to use a busy loop for delays, but
many people experience this when debugging their first blinking-led examples.

> However, many thanks.
> Tilmann

Regards,

Dominic Start a New Thread

--- In l..., Dominic Rath wrote:

> One thing that affects all GDB based solutions (plain GDB, Insight,
Eclipse)
> is that GDB sometimes fails to decide whether a source line should
be stepped
> using a breakpoint or by stepping until the next sourceline is
reached. This
> problem for example causes a "next" on a source line containing an
empty
> for-loop (for (i = 0; i < DELAY; i++);) to be stepped using single
assembly
> steps. OpenOCD might be able to execute up to 5 steps per second (never
> measured, just a guess), but stepping a delay loop that counts to
millions is
> going to take forever with this.
> I work around this by placing a temporary breakpoint (thbreak
> file.c:line-number) after the loop.

Hello Dominic,

I have read about this issue before - but that is not related to my
problem, AFAICS.

Here, every now and then Eclipse crashes and I have to terminate it
the "hardcore" way by closing its debug console window or by closing
it via Task Manager. The debug console seemingly does not provide any
real useful information...

Maybe I will also have to use plain GDB. I just thought it would be
nice to work from the same IDE all the time.

> Real world code is hopefully rarely going to use a busy loop for
delays, but
> many people experience this when debugging their first blinking-led
examples.

I can pretty well imagine that - but I'm already beyond this stage.
:-) My application almost perfectly runs with three real-time
interrupts, serial communication, ADC and some SPI I/O. Sometimes I
get an abort, however, so a working debugger would be nice to find the
cause.

I was however wondering if Eclipse (which seems to be a rather
commonly used IDE platform) really is that unstable, or if I'm just
doing something wrong...

Thanks again,
Tilmann Start a New Thread