I forgot to say that Julius pushed the patches to a new branch "adv_debug_sys" here http://git.openrisc.net/cgit.cgi/julius/openocd/

Franck.

The "burst write" is the standard way for adv_jtag_bridge to write data to the WishBone bus, there are dozens of these transactions during a debug session. More context would be helpful - when exactly in the process did this appear? Did the system work before or after?

I'm guessing this happened the first time the debugger tried to write data to the WishBone? If so, then your reset problem may fully explain this. The adv_dbg_if can't do WishBone transactions if the WishBone is in a constant reset state, which is what will happen if your reset is reversed. This will cause the error you're seeing.

Also, I'm curious what you mean when you say openOCD is "more stable" than adv_jtag_bridge...I haven't received any reports of adv_jtag_bridge crashing in quite some time.

Nathan,

Thanks a lot for your inputs ... adv_jtag_bridge is working fine now with ft245 ... usbblaster often keeps breaking ...

I've managed to re-synthesize the design (exactly the same as DE2-115 port of ORPSoC - which has been demonstrated to be working). Then I've gone onto create a u-boot image. Now once I load linux, set $pc to 0x100 in GDB, this is what get from adv_jtag_bridge:

*** stack smashing detected ***: ./adv_jtag_bridge terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0x2368d5]
/lib/i386-linux-gnu/libc.so.6(+0xe7887)[0x236887]
./adv_jtag_bridge[0x8053bba]
./adv_jtag_bridge[0x8054755]
./adv_jtag_bridge[0x805b31a]
./adv_jtag_bridge[0x805b92d]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d31)[0xaa5d31]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x2210ce]
======= Memory map: ========
0012f000-0014d000 r-xp 00000000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
0014d000-0014e000 r--p 0001d000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
0014e000-0014f000 rw-p 0001e000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
0014f000-002c5000 r-xp 00000000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002c5000-002c7000 r--p 00176000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002c7000-002c8000 rw-p 00178000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002c8000-002cb000 rw-p 00000000 00:00 0
00523000-0052e000 r-xp 00000000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
0052e000-0052f000 r--p 0000a000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
0052f000-00530000 rw-p 0000b000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
007e1000-007e8000 r-xp 00000000 08:01 1835107 /lib/libusb-0.1.so.4.4.4
007e8000-007e9000 r--p 00006000 08:01 1835107 /lib/libusb-0.1.so.4.4.4
007e9000-007ea000 rw-p 00007000 08:01 1835107 /lib/libusb-0.1.so.4.4.4
007ea000-007eb000 rw-p 00000000 00:00 0
00893000-008af000 r-xp 00000000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
008af000-008b0000 r--p 0001b000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
008b0000-008b1000 rw-p 0001c000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
009d0000-009d7000 r-xp 00000000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
009d7000-009d8000 r--p 00006000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
009d8000-009d9000 rw-p 00007000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
00a2a000-00a31000 r-xp 00000000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
00a31000-00a32000 r--p 00006000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
00a32000-00a33000 rw-p 00007000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
00a9f000-00ab6000 r-xp 00000000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
00ab6000-00ab7000 r--p 00016000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
00ab7000-00ab8000 rw-p 00017000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
00ab8000-00aba000 rw-p 00000000 00:00 0
00f3d000-00f3e000 r-xp 00000000 00:00 0 [vdso]
08048000-08065000 r-xp 00000000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08065000-08066000 r--p 0001c000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08066000-08067000 rw-p 0001d000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08067000-0806d000 rw-p 00000000 00:00 0
09dcd000-09e03000 rw-p 00000000 00:00 0 [heap]
b68b6000-b68b7000 ---p 00000000 00:00 0
b68b7000-b70b7000 rw-p 00000000 00:00 0
b70b7000-b70b8000 ---p 00000000 00:00 0
b70b8000-b78ba000 rw-p 00000000 00:00 0
b78c6000-b78c9000 rw-p 00000000 00:00 0
bf910000-bf931000 rw-p 00000000 00:00 0 [stack]

Any hints on where am I going wrong?

Many thanks!

Regards,
AR

@AR - The stacktrace you posted from the crash doesn't have function or line information for adv_jtag_bridge, so it's not very helpful in finding the crash. If you can reproduce this crash easily, try running adv_jtag_bridge inside of (x86) gdb, like so: linux> gdb --args adv_jtag_bridge gdb> run Then when it crashes, get the backtrace (just type 'bt' at the gdb prompt), and send that backtrace to me. That should include line numbers and functions, and I may be able to work out what happened from that.

Nathan,

sorry about the delayed response!

could not exactly create the same scenario ... here's how it went:

[1] Started adv_jtag_bridge inside gdb as you have said and ran with the usual arguments

(gdb) run -b ~/ ft245

Target device 0, JTAG ID = 0x020f70dd
IDCODE sanity test passed, chain OK!
[New Thread 0xb7feeb70 (LWP 2889)]
No watchpoint hardware found, HWP server not starting
JTAG bridge ready!

[2] In a new terminal, started another gdb session (as normal) and tried to connect to :9999 to load linux

This is what i get:

(gdb) target remote localhost:9999
Remote debugging using localhost:9999
Remote failure reply: E01

[3] Back trace from terminal 1:

CRC ERROR! Computed 0xd6508122, read CRC 0xd64911a7
Retry count exceeded! Abort!

Error while reading all registers: 'CRC mismatch'
^C
Program received signal SIGINT, Interrupt.
0x00130416 in __kernel_vsyscall ()
(gdb) bt
#0 0x00130416 in __kernel_vsyscall ()
#1 0x0022b40e in poll () from /lib/i386-linux-gnu/libc.so.6
#2 0x0804c1d8 in handle_rsp () at rsp-server.c:403
#3 0x08049ef5 in main (argc=4, argv=0xbffff7d4) at adv_jtag_bridge.c:530

How can I start 2 gdb sessions and make them talk to each other? Any ideas?

Regards,
AR

You have a genuine CRC error there...this is the first time I've ever actually seen one. A CRC mismatch indicates one or more bit errors in transmission...the adv_dbg_if computes a CRC on the data it sends, adv_jtag_bridge computes a CRC on the data it receives, and if the data is the same, the CRC matches. If not, then what was sent is different than what was received.

Two possibilities come to mind. First, a configuration problem. Do the configurations for your adv_dbg_if hardware match what you set when building adv_jtag_bridge? The most likely mismatch is "high speed mode," but there are other possibilities. Make sure the two are set up the same, and make sure to recompile after you reconfigure (possibly requiring a 'make clean').

The second possibility is a genuine run-time bit error. This could be caused by a JTAG clock (generated by the cable) that's too fast for your SoC - check your synthesis logs for timing warnings. Electrical noise and a flaky connection are also possibilities, but much less likely. If the JTAG clock is too fast, there are are ways for adv_jtag_bridge to slow down the usb-blaster driver (by applying patches to the code), but they're very, very slow. If there's a way to tell the cable to slow down just a little, I don't know what it is.

Hi,

I had such systematic CRC errors too. My board configuration was good (because I did not have CRC errors using the Quartus Tcl console with a custom script or OpenOCD).I didn't think this could be the JTAG clock speed so I let it down and moved to OpenOCD. However, it would be interesting to slow down the clock and see if it works...

Franck.

Last time I've checked the high speed option was enabled in both software and hardware ...
One interesting observation: CRC errors do not appear when I load linux onto sdram using 'load vmlinux' in GDB ... I get a transfer rate of ~13 Kbps even with high speed option enabled. But once loading finishes and I execute these commands 'set $pc 0x100' and 'continue', CRC error appears (other errors appear at times e.g: can't read 0x00 etc). I'm using the DE2-115 board specific RTL for ORSoC. The guy who ported this to the DE2-115 board (Cosmin Gorgovan) confirmed that the RTL works.



Just out of interest, what's the clock frequency of the jtag clock?

Regards,
AR

Franck,

Is there a JSP alternative for OpenOCD? Or can you tell me how to get the linux serial console through JTAG USB? I've tried connecting to ttyUSBx using Minicom/Picocom but they don't seem to work ...

Many thanks.

For now, you can't use the JSP with OpenOCD.

Why don't you use the serial port available on your DE2-115 board ?

Franck.

Simple reason: i dont have a serial cable :-( but looks like have to get one.

Some interesting things here. First item: I don't know what the clock speed of a real USB-Blaster is, mine is a clone, with an internal clock of 24MHz. So, no more than 24MHz, possibly half that.

Second, 13k / second is not very good. I get ~88k / second downloading large files to RAM with my clone cable and a native Linux host system. There are many places you could be losing speed. This is not critical, if 13k / sec is fast enough for you...but it's possible to do better (with adv_jtag_bridge).

Third, it sounds like you have no problem accessing the RAM on the SoC Wishbone bus through adv_jtag_bridge. But, you get CRC errors when you try to access the CPU. It is possible that there is a bug in the adv_dbg_if logic in the CPU access module, but not especially likely - it shares most of its design with the bus access unit. It is possible that there is a bug or timing issue when accessing 32-bit values through the adv_dbg_if - code is downloaded to RAM using 8-bit transfers, but CPU register access uses 32. It is also possible that there is a critical timing path in the CPU that is not supplying the value to the debug interface quickly enough.

Two question: First, what version of the OR1200 are you using? V1, v2, v3?
Second, what happens when you run the adv_jtag_bridge self test (put the -t option on the command line)?

I believe I'm using the latest one (v3) ... I've checked out the latest version of orsoc from repo ... I haven't had the time to check the design with v1 or v2 ...



SRAM test passes ... CPU test fails ...

I'm using a linux vm ... may be thats why I'm losing speed ...

Hi Nathan,

I've resynthesized my design with or1200 release 2. Here's how it went:

[1] CPU and SRAM self-test passed successfully.

*** Doing self-test ***
Stall or1k - CPU(s) stalled.
SRAM test:
expected 11112222, read 11112222
expected 33334444, read 33334444
expected 55556666, read 55556666
expected 77778888, read 77778888
expected 9999aaaa, read 9999aaaa
expected bbbbcccc, read bbbbcccc
expected ddddeeee, read ddddeeee
expected ffff0000, read ffff0000
expected dedababa, read dedababa
SRAM test passed
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 = 00000010 ppc = 00000028 r1 = 00000008
Expected npc = 00000010 ppc = 00000028 r1 = 00000008
Read npc = 00000028 ppc = 00000024 r1 = 0000000b
Expected npc = 00000028 ppc = 00000024 r1 = 0000000b
Read npc = 00000024 ppc = 00000020 r1 = 00000018
Expected npc = 00000024 ppc = 00000020 r1 = 00000018
Read npc = 00000020 ppc = 0000001c r1 = 00000031
Expected npc = 00000020 ppc = 0000001c r1 = 00000031
Read npc = 00000024 ppc = 00000020 r1 = 00000032
Expected npc = 00000024 ppc = 00000020 r1 = 00000032
Read npc = 00000014 ppc = 00000010 r1 = 00000063
Expected npc = 00000014 ppc = 00000010 r1 = 00000063
Read npc = 00000028 ppc = 00000024 r1 = 00000065
Expected npc = 00000028 ppc = 00000024 r1 = 00000065
Read npc = 00000010 ppc = 00000028 r1 = 000000c9
Expected npc = 00000010 ppc = 00000028 r1 = 000000c9
result = deaddead
*** Self-test PASSED ***

[2] Tried to load u-boot/linux ... went well ... same speed as before was achieved 13 kbps ... tried to set $pc to 0x100 and adv_jtag_bridge crashed ...

*** stack smashing detected ***: /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0x24b8d5]
/lib/i386-linux-gnu/libc.so.6(+0xe7887)[0x24b887]
/opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge[0x8053bba]
/opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge[0x8054755]
/opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge[0x805b31a]
/opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge[0x805b92d]
/lib/i386-linux-gnu/libpthread.so.0(+0x6d31)[0x137d31]
/lib/i386-linux-gnu/libc.so.6(clone+0x5e)[0x2360ce]
======= Memory map: ========
00110000-0012e000 r-xp 00000000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
0012e000-0012f000 r--p 0001d000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
0012f000-00130000 rw-p 0001e000 08:01 1835151 /lib/i386-linux-gnu/ld-2.13.so
00130000-00131000 r-xp 00000000 00:00 0 [vdso]
00131000-00148000 r-xp 00000000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
00148000-00149000 r--p 00016000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
00149000-0014a000 rw-p 00017000 08:01 1836070 /lib/i386-linux-gnu/libpthread-2.13.so
0014a000-0014c000 rw-p 00000000 00:00 0
0014c000-00153000 r-xp 00000000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
00153000-00154000 r--p 00006000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
00154000-00155000 rw-p 00007000 08:01 1839269 /lib/i386-linux-gnu/librt-2.13.so
00155000-0015c000 r-xp 00000000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
0015c000-0015d000 r--p 00006000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
0015d000-0015e000 rw-p 00007000 08:01 1972457 /usr/lib/i386-linux-gnu/libftdi.so.1.19.0
0015e000-00162000 r-xp 00000000 08:01 2372846 /usr/local/lib/libusb-0.1.so.4.4.4
00162000-00163000 r--p 00003000 08:01 2372846 /usr/local/lib/libusb-0.1.so.4.4.4
00163000-00164000 rw-p 00004000 08:01 2372846 /usr/local/lib/libusb-0.1.so.4.4.4
00164000-002da000 r-xp 00000000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002da000-002dc000 r--p 00176000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002dc000-002dd000 rw-p 00178000 08:01 1835154 /lib/i386-linux-gnu/libc-2.13.so
002dd000-002e0000 rw-p 00000000 00:00 0
002e0000-002ed000 r-xp 00000000 08:01 1836015 /lib/i386-linux-gnu/libusb-1.0.so.0.0.0
002ed000-002ee000 r--p 0000c000 08:01 1836015 /lib/i386-linux-gnu/libusb-1.0.so.0.0.0
002ee000-002ef000 rw-p 0000d000 08:01 1836015 /lib/i386-linux-gnu/libusb-1.0.so.0.0.0
002ef000-002fa000 r-xp 00000000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
002fa000-002fb000 r--p 0000a000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
002fb000-002fc000 rw-p 0000b000 08:01 1835163 /lib/i386-linux-gnu/libnss_files-2.13.so
002fc000-00318000 r-xp 00000000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
00318000-00319000 r--p 0001b000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
00319000-0031a000 rw-p 0001c000 08:01 1835961 /lib/i386-linux-gnu/libgcc_s.so.1
08048000-08065000 r-xp 00000000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08065000-08066000 r--p 0001c000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08066000-08067000 rw-p 0001d000 08:01 1979911 /opt/or1k-oshug/adv_debug_sys/trunk/Software/adv_jtag_bridge/adv_jtag_bridge
08067000-080a0000 rw-p 00000000 00:00 0 [heap]
b6feb000-b6fec000 ---p 00000000 00:00 0
b6fec000-b77ec000 rw-p 00000000 00:00 0
b77ec000-b77ed000 ---p 00000000 00:00 0
b77ed000-b7ff0000 rw-p 00000000 00:00 0
b7ffd000-b8000000 rw-p 00000000 00:00 0
bffdf000-c0000000 rw-p 00000000 00:00 0 [stack]

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb77ebb70 (LWP 2344)]
0x00130416 in __kernel_vsyscall ()

Backtrace output:

(gdb) bt
#0 0x00130416 in __kernel_vsyscall ()
#1 0x00191c8f in raise () from /lib/i386-linux-gnu/libc.so.6
#2 0x001952b5 in abort () from /lib/i386-linux-gnu/libc.so.6
#3 0x001c7dfc in ?? () from /lib/i386-linux-gnu/libc.so.6
#4 0x0024b8d5 in __fortify_fail () from /lib/i386-linux-gnu/libc.so.6
#5 0x0024b887 in __stack_chk_fail () from /lib/i386-linux-gnu/libc.so.6
#6 0x08053bba in adbg_jsp_transact (bytes_to_send=0xb77eb1f4,
data_to_send=0xb77eb1fc " `06\bt-23", bytes_received=0xb77eb1f8,
data_received=0xb77eb204 "") at adv_dbg_commands.c:908
#7 0x08054755 in dbg_serial_sndrcv (bytes_to_send=0xb77eb1f4,
data_to_send=0xb77eb1fc " `06\bt-23", bytes_received=0xb77eb1f8,
data_received=0xb77eb204 "") at dbg_api.c:679
#8 0x0805b31a in jsp_hardware_transact () at jsp_server.c:527
#9 0x0805b92d in jsp_server (arg=0x0) at jsp_server.c:351
#10 0x00137d31 in start_thread () from /lib/i386-linux-gnu/libpthread.so.0
#11 0x002360ce in clone () from /lib/i386-linux-gnu/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind further

I thought reverting to release 2 would sort this issue out but it didn't. Could this be an issue with GDB 7.2 ???

Would slowing down the bus & cpu clock speed do any good ???

N.B: My linux image works fine on or1ksim ... so this can not be an issue with linux image
...
Please help!

Regards,
AR