IOTDK+OpenOCD+OLIMEX+Linux Userspace Debugging

[Dallas_P_]

I'm trying to get OCD working with the IOTDK to debug Userspace programs via JTAG.  I know it has been done with the Kernel and I did use the intel documentation on the subject as a starting point.  However, debugging the kernel is slightly (maybe more than slightly) different.  I suppose debugging 1_c_helloworld is more akin to debugging a kernel module as it is located where the Kernel decides to put it at run time and runs under a process created by the kernel.

I had no real problem getting OpenOCD to talk with GDB.  Here's some evidence:

Info : 274 252 server.c:83 add_connection(): accepting 'gdb' connection from 3333
Debug: 275 252 breakpoints.c:359 breakpoint_clear_target_internal(): Delete all breakpoints for target: quark_x10xx.cpu
Debug: 276 252 breakpoints.c:499 watchpoint_clear_target(): Delete all watchpoints for target: quark_x10xx.cpu
Debug: 277 252 target.c:1401 target_call_event_callbacks(): target event 23 (gdb-attach)
Debug: 278 252 gdb_server.c:986 gdb_new_connection(): New GDB Connection: 1, Target quark_x10xx.cpu, state: running
Debug: 279 252 gdb_server.c:2662 gdb_input_inner(): received packet: 'qSupported:multiprocess+;xmlRegisters=i386;qRelocInsn+'

But things go south pretty quick from there.  First thing that looks really fishy is this:

Debug: 356 253 gdb_server.c:2662 gdb_input_inner(): received packet: 'QStartNoAckMode'
Debug: 357 254 gdb_server.c:632 gdb_get_packet_inner(): Received first acknowledgment after entering noack mode. Ignoring it.
Debug: 358 254 gdb_server.c:2662 gdb_input_inner(): received packet: 'Hg0'
Debug: 359 254 gdb_server.c:2662 gdb_input_inner(): received packet: 'qXfer:features:read:target.xml:0,fff'

OpenOCD responds with the Register Set (all set to zero which is fairly odd) and then spits out  a load of these:

Debug: 518 265 x86_32_common.c:86 x86_32_get_gdb_reg_list(): value pmcr = 00000000
Error: 519 265 lakemont.c:220 check_not_halted(): target running, halt it first
Error: 520 265 lakemont.c:220 check_not_halted(): target running, halt it first

There are 75 of these errors and there are 75 registers so I suppose that are correlated.  Anyway things don't get better and it is clear later on in the debug output of OpenOCD that GDB thinks it is debugging code at address 0.  That can't be right.  And the thread ID of 0 in the 'Hg0' command is a bit suspicious.

Anybody else tried this shenanigan or am I the only one fool enough?

Thanx for any insight,

Dallas

[Paul_F_Intel]

Hi Dallas,

I can confirm that OpenOCD works with the Galileo  - I have personally used it to debug firmware and kernel.
I assume you are using a Galileo?

It is interesting that you want to use JTAG debugging for user space - I am curious why, would you mind sharing?

I thought it would be much easier to use gdb on the target?
If you want to debug remotely gdbserver on the Galileo and connect to that is also an option, which should be easier to get going.

If you want to get OpenOCD going, can you tell us what version of tools you are using  (OpenOCD, ... , gdb, what host OS)? What JTAG probe do you have? USB drivers?

We may be able to find out if there are any known issues.

Regards,

Paul