RE: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

RE: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

["Dörr, Dirk"]

Paul Whitfield wrote:


>(gdb) tk gdb_target_has_execution
>0

>(gdb) tk set ::gdb_running
>0

I get the same results on my system

-- 


Dirk Dörr
mailto:dirk.doerr@3soft.de 

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Paul Whitfield]

Dörr, Dirk wrote:

> Paul Whitfield wrote:
> 
> 
> 
>>(gdb) tk gdb_target_has_execution
>>0
> 
> 
>>(gdb) tk set ::gdb_running
>>0

I took the code and added the line

    inferior_ptid = pid_to_ptid (42000);	/* Make run command think we 
are busy... */

This now enables all the buttons.

But if I attempt to load a new file, then get the following
sequence

Insight tells me that a debugging session is in progress and do
I want to end it.

Then when I attempt to load the file I get an error
(If I load the file from the console by typing "load file.elf" it
works without error).

After this the buttons are confused again.
Checking the settings again

gdb_target_has_execution is 1,::gdb_running is still 0.

Looks like I have not quite found the right spot to
set the pid!

Also if I load my program by scripts and start everything
running I have the same problem when I hit the first
breakpoint, i.e. insight thinks that the target
is not running again.



Regards

Paul

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Mon, 2003-10-06 at 18:17, Paul Whitfield wrote:
> >>(gdb) tk gdb_target_has_execution
> >>0
> > 
> > 
> >>(gdb) tk set ::gdb_running
> >>0

This definitely indicates an error in the target support...

> I took the code and added the line
> 
>     inferior_ptid = pid_to_ptid (42000);	/* Make run command think we 
> are busy... */

Where did you put this? According to monitor.c, it should be set
TARGET_open.

> This now enables all the buttons.
> 
> But if I attempt to load a new file, then get the following
> sequence

This might be the correct behavior. What exactly did you do? FWIW, JUST
hit the Run button. It will attach, download, and continue the target
(which is the most common way of using remote targets).

> Insight tells me that a debugging session is in progress and do
> I want to end it.
> 
> Then when I attempt to load the file I get an error

What error?

> Also if I load my program by scripts and start everything
> running I have the same problem when I hit the first
> breakpoint, i.e. insight thinks that the target
> is not running again.

That doesn't altogether suprise me. But let's address these issues one
at a time.

Keith

RE: Problems using Insight/GDB for Coldfire

["Dörr, Dirk"]

Hi!

On Wed, 2003-09-17 at 16:35, Keith Seitz wrote: (@ insight@sources.redhat.com list):

> Ok, I would just whack everything below the "target" command from your
> .gdbinit and save it into another file. You can use the "Command to run
> after attaching to target" thingy in the target selection to source in
> the other script. (So, save everything below the "target" command into,
> e.g., ~/setup-bdm; then open a target selection dialog (File->Target
> Settings...), select the BDM target, fold down the "More Options" thingy
> and type in the "Command to run after attaching" something like "source
> ~/setup-bdm

Executing the init sequence after starting insight improves the situation. 

But there are still problems like losing focus in source, 
register changes are not displayed ...

I get the impression that there is a general problem with bdm and gdb...

I contacted Thomas Elter from embeddedtools.net (they sell the microcross 
gcc based cross-tools) and got this answer:


> [... Snip ...] 
> It appears that the main problem in your development environment is the P&E Micro 
> connection device. It turns out that the P&E Micro connection device, is not compatible with any GNU
> tool suite release from any vendor. The P&E Micro connection device will
> download the object load module to the target, but will not support any
> debug activities with a GNU Debugger like GDB. Microcross made an attempt to
>work with them to find a solution, but they were not interested.

He offers a Abatron BDI2000 and an other BDM interface from Cybertec

Ok. BDI2000 uses tcp/ip remote debugging. But the bdm inteface from cybertec? 
There should be no big difference between this one and the P&E device? 
Both using parallel port.

So my question: 

Is anybody else using the P&E BDM Interface for Coldfire with Insight/gdb
or can confess the compatibility problems of P&E? 



Bye

-- 

Dirk Dörr

Sorry for crossposting! 

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Chris Johns]

Dörr, Dirk wrote:
> 
> I get the impression that there is a general problem with bdm and gdb...
> 

This could be true, and Insight shows the problems. People do use Insight, how-ever I 
do not, so I have to assume it works.

> But the bdm inteface from cybertec? 

The Cybertec pod works with the BDM driver on SF and the BDM driver supports GDB with 
the GDB patch also on SF.

-- 
  Chris Johns, cjohns at cybertec . com . au

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Paul Whitfield]

Dörr, Dirk wrote:

> Hi!
> 
> On Wed, 2003-09-17 at 16:35, Keith Seitz wrote: (@ insight@sources.redhat.com list):
> 
> 
>>Ok, I would just whack everything below the "target" command from your
>>.gdbinit and save it into another file. You can use the "Command to run
>>after attaching to target" thingy in the target selection to source in
>>the other script. (So, save everything below the "target" command into,
>>e.g., ~/setup-bdm; then open a target selection dialog (File->Target
>>Settings...), select the BDM target, fold down the "More Options" thingy
>>and type in the "Command to run after attaching" something like "source
>>~/setup-bdm
> 
> 
> He offers a Abatron BDI2000 and an other BDM interface from Cybertec
> 
> Ok. BDI2000 uses tcp/ip remote debugging. But the bdm inteface from cybertec? 
> There should be no big difference between this one and the P&E device? 
> Both using parallel port.
> 
> So my question: 
> 
> Is anybody else using the P&E BDM Interface for Coldfire with Insight/gdb
> or can confess the compatibility problems of P&E? 
> 

I have used both Cybertec and P&E BDM Interfaces extensively with 
command line gdb without any dramas. As far as I know the P&E is
functional the same as the Cybertec part (at least ours was
until we let one of the ham fisted engineers take it onsite
and kill it!)

I have been attempting to use insight (recent snapshot and bdm patches 
from CVS) on Cygwin. Until recently I could not get a build of insight
and bdm/gdb that would work nicely together on cygwin.

I can get basic functionality to work, i.e. download to ram, breakpoints
after having loaded a .gdbinit file that sets up my hardware correctly.

However, the insight GUI seems to have problems understanding the 
current state of the interface. I.e. the buttons on the top
of the window are always greyed out.

Also I have been having problems with this combo getting watchpoints
to work (this is definitely a bdm/gdb issue).

I hope to spend some more time on this soon, but sadly I am current
doing too many other things to actually get this tested / setup as
well as I would like.

Regards

Paul

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Wed, 2003-10-01 at 00:20, Paul Whitfield wrote:
> However, the insight GUI seems to have problems understanding the 
> current state of the interface. I.e. the buttons on the top
> of the window are always greyed out.

This is almost always a bug in the backend support for gdb. Do -- all
from the console window:

1) tk ManagedWin::open DebugWin
2) [set baudrate or any other target options]
3) target MYTARGET DEVICE
4) tk gdb_target_has_execution
5) tk set ::gdb_running

Notice that if the backend is operating properly, the answer to both #3
and #4 will be >0. Any errors show up in the debug window?

Keith

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Paul Whitfield]

Keith Seitz wrote:

> On Wed, 2003-10-01 at 00:20, Paul Whitfield wrote:
> 
>>However, the insight GUI seems to have problems understanding the 
>>current state of the interface. I.e. the buttons on the top
>>of the window are always greyed out.
> 
> 
> This is almost always a bug in the backend support for gdb. Do -- all
> from the console window:

One thing... I usually do the target stuff in my .gdbinit file.
Because this is a embedded environment there is a reasonable
amount of setup that needs to be done before it is possible
to communicate with the board (mainly making sure the
memory space is working so there is valid memory to
examine / download into).

Also there procedures vary depending on if I am debugging
code in RAM or in Flash memory, so I have a couple of
diffent init scripts that I run depending on the circumstances.

Is this an issue with Insight?

> 
> 1) tk ManagedWin::open DebugWin
> 2) [set baudrate or any other target options]
> 3) target MYTARGET DEVICE
> 4) tk gdb_target_has_execution
> 5) tk set ::gdb_running
> 

Here is the output from the console window.

gdb) tk ManagedWin::open DebugWin
.debugwin0.debugwin

(gdb) target bdm /dev/bdmcf0
Remote bdm connected to /dev/bdmcf0
  Coldfire debug module version is 1 (5307/5407(e))

(gdb) tk gdb_target_has_execution
0

(gdb) tk set ::gdb_running
0

(gdb)


> Notice that if the backend is operating properly, the answer to both #3
> and #4 will be >0. Any errors show up in the debug window?

As you can see the answers are 0.... no errors in the debug window.

So any pointers to code / documentation for what needs to be
fixed to make the back end work correctly?


Thanks

Paul

Re: [Bdm-devel] RE: Problems using Insight/GDB for Coldfire

[Keith Seitz]

On Thu, 2003-10-02 at 18:20, Paul Whitfield wrote:
> (gdb) target bdm /dev/bdmcf0
> Remote bdm connected to /dev/bdmcf0
>   Coldfire debug module version is 1 (5307/5407(e))
> 
> (gdb) tk gdb_target_has_execution
> 0

This is a problem. This indicates a problem with the target backend.
It's not setting the pid/ptid when the target is attached. See
src/gdb/gdbtk/generic/gdbtk-cmds.c:gdb_target_has_execution_command.

Normally, one of the target vector commands will set ptid (or pid for
older versions of gdb) to non-zero -- typically 42000 or some other
"significant" number.

If you have the source code for the backend, check that something in the
target vector sets the ptid on attach. (See, for example, monitor_open
in monitor.c, which sets "inferior_pid = pid_to_ptid (42000);".

Keith