Advanced Debug System

Hi Nathan!

I have detected some problems while working with adv_jtag bridge, legacy debug interfaces and GDB 6.8 and 5.3. I have been trying to detect what is going wrong and I think that it is about pthread mutex locking. I've tested with xilinx usb, xpc3 and ft2232 with no changes.

GDB returns the following:

jose@menlopark:~/unison/proyectos/S3E/tools/or32_toolchain/mof-orsoc/or32-elf/bin$ sudo ./or32-elf-gdb
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=or32-elf".
(gdb) target remote :9999
Remote debugging using :9999
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing... 
...

No matters how long you wait, it keeps returning packet errors ... Ignoring packet error, continuing... Ignoring packet error, continuing...

Tracing the behaviour of adv_jtag_bridge it shows the following:

jose@menlopark:~/unison/proyectos/S3E/tools/or32_toolchain/jtag/legacy/adv_debug_sys/trunk/Software/adv_jtag_bridge$ sudo ./adv_jtag_bridge -g 9999 -x0 -l 0:4 -c 0x08 -t xpc3
[sudo] password for jose:
Connected to parallel port at 378
Dropping root privileges.
Enumerating JTAG chain...

Devices on JTAG chain:
Index    Name        ID Code        IR Length
----------------------------------------------------------------
0:     (unknown)     0x149511C3     -1

Target device 0, JTAG ID = 0x149511c3
Prefix bits: 0
Using command-line debug command 0x8
*** 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 ***
JTAG bridge ready!
Handling RSP
Packet received qSupported: 10 chars
Putting PacketSize=119
Packet received ?: 1 chars
Putting S00
Packet received Hc-1: 4 chars
Putting OK
Packet received qC: 2 chars
Putting
Packet received Hg0: 3 chars
Putting OK
Packet received g: 1 chars

It hangs after receiving "g" and don't send any answer. I think it is a deadlock issue When tracing locks and unlocks along the execution we can see:

1: rsp_read_all_regs () calls dbg_cpu0_read_block() 2: dbg_cpu0_read_block() locks dbg_access_mutex 3: dbg_cpu0_read_block() calls dbg_cpu0_read() 4: dbg_cpu0_read() tries to lock and hangs because dbg_cpu0_read_block() has already locked and is waiting for dbg_cpu0_read() to finish before it unlocks and dbg_cpu0_read() is waiting for dbg_cpu0_read_block() to unlock before it can continue.

Hope this info helps to solve the bug. It is strange that there aren't more people experiencing it...

Regards José Ignacio Villar

There were two similar mutex-related bugs. Both should be fixed now in the TRUNK branch.