OpenCores
no use no use 1/1 no use no use
Unable to step through code with GDB
by rcrowell on Oct 7, 2010
rcrowell
Posts: 2
Joined: Sep 2, 2008
Last seen: Apr 12, 2019
Hi all,

I am having trouble running and debugging the UART code from the minsoc project. There are at least two issues, I think. First, here's a description of my setup:

I'm using the Xilinx ML401 development board which contains a Virtex-4 FPGA. For synthesis and PAR I'm using Xilinx's ISE 12.1 software and I've got a DLC9 jtag cable (very very slow!!!)

I've checked the latest minsoc, or1200, adv_debug_sys and uart16550 code out from the SVN archives and I built the GNU toolchain using the MOF_ORSOC_TCHN_v5c_or32-elf.sh script.

Following the INSTALL.pdf file from minsoc, I built adv_jtag_bridge and patched and recompiled GDB. No problems with any of these procedures. I followed the HOWTO.pdf file from minsoc to compile the code in sw/support, sw/utils and sw/uart - all built cleanly. I then synthesized and PAR'd the FPGA design, and programmed the configuration PROM on the development board.

Problem number 1:
I copied all appropriate .bsd files into my home directory and ran the adv_jtag_bridge software in self-test mode, with this command: "adv_jtag_bridge.exe -t -x 1 xpc_usb". The jtag chain enumerates correctly, the SRAM test completes successfully, but the CPU test fails with the following results:

Testing CPU0 (or1k) - writing instructions
Setting up CPU0
Starting CPU0!
Read npc = 00000010 ppc = 00000028 r1 = 00000005
Expected npc = 00000010 ppc = 00000028 r1 = 00000005
Read npc = 00000028 ppc = 00000028 r1 = 00000008
Expected npc = 00000010 ppc = 00000028 r1 = 00000008
Read npc = 00000024 ppc = 00000020 r1 = 0000000b
Expected npc = 00000028 ppc = 00000024 r1 = 0000000b
Read npc = 00000020 ppc = 00000020 r1 = 00000018
Expected npc = 00000024 ppc = 00000020 r1 = 00000018
Read npc = 0000001c ppc = 00000018 r1 = 00000031
Expected npc = 00000020 ppc = 0000001c r1 = 00000031
Read npc = 00000020 ppc = 0000001c r1 = 00000032
Expected npc = 00000024 ppc = 00000020 r1 = 00000032
Read npc = 00000010 ppc = 00000028 r1 = 00000063
Expected npc = 00000014 ppc = 00000010 r1 = 00000063
Read npc = 00000010 ppc = 00000028 r1 = 00000063
Expected npc = 00000028 ppc = 00000024 r1 = 00000065
Read npc = 00000010 ppc = 00000028 r1 = 00000094
Expected npc = 00000010 ppc = 00000028 r1 = 000000c9
result = deaddef0
Self-test FAILED *** Bailing out!

Problem number 2:
I decided to ignore the above error for the time being. Continuing to follow HOWTO.pdf, I start up the adv_jtag_bridge in normal mode like this: "adv_jtag_bridge.exe -x 1 xpc_usb" and then fire up gdb like this: "or32-elf-gdb uart-nocache.or32". I then execute the following GDB commands:

target remote :9999
load
set $pc=0x100
c

As expected, I get "Hello World." in my terminal and if I send any characters to the FPGA I get the expected characters back on the terminal (input char + 1).

I then restarted GDB, reloaded the application into memory, and set the $pc value. Before executing the continue command, I set up a breakpoint with "b main". When I continue execution, the program reaches the breakpoint and stops:

Breakpoint 1, main () at uart.c:96
96 uart_init();
(gdb)

At this point I am completely unable to continue program execution, however. Whether I issue the GDB "next", "step", or "continue" commands, I always just end up back at my breakpoint for some reason. It's as if the application started over again and re-entered the main() function.

Do any of you have any ideas or suggestions? I apologize for the length of this post, but I wanted to get all of the details in.

Thanks for any help!
RE: Unable to step through code with GDB
by nyawn on Oct 8, 2010
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023
This is a bug in the current versions of the OR1200 CPU (v3). The current version (SVN rev. 388) has a bug related to the hardware single-step function. The maintainers have improved the behavior some, but it's still a problem.

I recommend you checkout an older tag of the OR1200, and use that. Unless there's something in the OR1200v3 you really need, the OR1200v1 will work just fine, and it doesn't have the single-step bug.

Sorry about the speed with the DLC9...complain to Xilinx, and ask them to open up their protocol specification. Or, if you'd care to reverse-engineer the protocol, send me a patch and I'll be happy to integrate it...
RE: Unable to step through code with GDB
by rcrowell on Oct 11, 2010
rcrowell
Posts: 2
Joined: Sep 2, 2008
Last seen: Apr 12, 2019
Thanks for the pointer! I had previously searched the forum and bug tracker but didn't see any references to such a problem in either place. I checked out the tag labeled "rev2" from the SVN archive of the or1200 code and I can now single step without trouble. However, I do need some of the rev3 features like the FPU, so hopefully this will get fixed in the near future.
RE: Unable to step through code with GDB
by nassim09 on Apr 9, 2011
nassim09
Posts: 32
Joined: Nov 13, 2008
Last seen: May 7, 2020
This is a bug in the current versions of the OR1200 CPU (v3). The current version (SVN rev. 388) has a bug related to the hardware single-step function. The maintainers have improved the behavior some, but it's still a problem.

I recommend you checkout an older tag of the OR1200, and use that. Unless there's something in the OR1200v3 you really need, the OR1200v1 will work just fine, and it doesn't have the single-step bug.

Sorry about the speed with the DLC9...complain to Xilinx, and ask them to open up their protocol specification. Or, if you'd care to reverse-engineer the protocol, send me a patch and I'll be happy to integrate it...


Any news Nyawn about adv_debug_system for OR1200 V3?
RE: Unable to step through code with GDB
by nyawn on Apr 10, 2011
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023


Any news Nyawn about adv_debug_system for OR1200 V3?


So far as I know, the OR1200 maintainers have not made any changes in this area. So, I think the problem is unchanged. I sent them a testbench several months ago which can reproduce the problem in a simulation, but I haven't heard anything back, and I've been too busy to look into it myself.

I have made a little progress on DLC9 support, though.
RE: Unable to step through code with GDB
by julius on Apr 10, 2011
julius
Posts: 363
Joined: Jul 1, 2008
Last seen: May 17, 2021
Yes, not yet looked into this for the advanced debug system unfortunately. I believe the issue is to do with the OR1200 debug unit in general and is not specific to any particular debug interface. The basics work with software breakpoints and single stepping, but I think no HW breakpoint stuff is going yet. We'd definitely appreciate patches for this.
RE: Unable to step through code with GDB
by nyawn on Apr 11, 2011
nyawn
Posts: 173
Joined: Dec 19, 2008
Last seen: May 31, 2023
Yes, not yet looked into this for the advanced debug system unfortunately. I believe the issue is to do with the OR1200 debug unit in general and is not specific to any particular debug interface. The basics work with software breakpoints and single stepping, but I think no HW breakpoint stuff is going yet. We'd definitely appreciate patches for this.


In my testing, the basics don't work. Single-stepping fails after a few steps when debugging code on FPGA hardware. Software breakpoints may or may not work reliably - a single-step always locked up the CPU before I tried a breakpoint when debugging a regular program. I don't remember what exactly in the self-test causes the lockup, it might also be a single-step.
no use no use 1/1 no use no use
© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.