I load a simple main.elf(-g -O0 -mboard=ordb2a) on ordb2a-ep4ce22,
and try to debug with GDB.
The first break is "b main", and it works.
I can use s or si here after.

But when I set a second break,
it runs to the breakpoint, and then trapped.
Does someone debug a program on ordb2a-ep4ce22 successfully?

BTW, does the memory map of SDRAM start from 0x00000000 ?

Hi Derek,

It should work. Could you post a log of your GDB session. It would help if you would issue the command

set debug remote 1

as your first GDB command. Then we can see what was happening through the remote serial protocol interface.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Thanks for you suggestion, here is the log file.

As usual, when I finish loading the file,
I set "b main", and then "c".
(main func starts from 0x800000, breakpoint is at 0x80000c)

It did stop at main(), then I input "si",
the program counter didn't move on, and it's trapped.

It seems PPC should be the value of breakpoint 0x80000c,
but actually it's 0x800008.

Is it a hardware problem or the toolchain ?
I use this image "OpenRISC_Ubuntu_2011-12-15.vdi"

Thanks!

Hi Derek,

I need the log interspersed with the GDB session, so I can see what commands generate what traffic. Various ways of doing this, but the simplest is to just run under script:

$ script /tmp/log.txt
$ gdb <gdb arguments>
(gdb) set debug remote 1
...
<your gdb commands here>
...
(gdb) quit
$ ctrl-D

The final ctrl-D closes the script file. Then post /tmp/log.txt.

HTH

Jeremy

Hi Jerermy,

Here is the log dump from script.
I don't why there is so much garbage characters,
Hope you can read it.

Thanks,

Hi Derek,

Good lord - I don't know what happened there. Must be some sort of fancy graphics terminal emulator you have. This is unusable. Could try again a different way!

$ or32-elf-gdb <gdb arguments> 2>&1 | tee /tmp/log.txt
(gdb) set debug remote 1
...
(gdb) quit
$

Hopefully that will do a better job.

Jeremy

Hi Jeremy,

This one looks much better!
Hope it could help.

Highly appreciate,
Derek

Hi Derek,

OK - looks like the si is not single stepping an instruction. The g packet is showing the registers being read back, and it looks like PPC/NPC is not changing.

What is the target you are using? And how are you connecting the debugger to it. As far as I can see, GDB is sending the right commands, the target is not responding as expected.

Jeremy

Hi Jeremy,

As far as I know is that I connect "ordb2a-ep4ce22" to "or_debug_proxy" through a usb-to-jtag cable.
Or_debug_proxy has checked out the latest version from svn,
but I don't know which version of the openrisc core is used.
Also the privilege of the cable read/write setting is 666.

I have tried another client "OpneOCD" with GDB, but it didn't work.
What should be the next move I take?

Highly appreciate,
Derek

We at ORSoC have with the aid of this report found a bug (deadlock between debug unit and pipeline of OR1200) which causes these symptoms, and produced a patch for it (openrisc svn revision 815, also http://lists.opencores.org/pipermail/openrisc/2012-September/000921.html ). I'll see about producing an updated RBF for the ORDB2A board, or you could synthesize one with Quartus.