Intel Quark+Eclipse+Olimex+Userspace Linux

I’m trying to get Eclipse and OpenOCD to work with an Olimex ARM USB OCD H adapter to debug userspace programs. No real problem getting everything talking but can’t seem to get the GDB client and the JTAG adapter to play nice together. I’ve read the Intel document on using this configuration to debug the Linux kernel itself which is close to what I want but not exactly. The kernel is static (if you ignore modules) but a user space program isn’t. That seems to be part of the problem. Everything seems kosher until GDB tries to read the target configuration with:

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’

I see the server respond with the registers (which is seem to do a lot), and then I get a long string of:

Error: 519 265 lakemont.c:220 check_not_halted(): target running, halt it first

Then the client tries to read some memory @ address 0 (that has to be wrong??) and get more complaints about the target running:

Debug: 594 266 gdb_server.c:2662 gdb_input_inner(): received packet: ‘m0,1’

Debug: 595 266 gdb_server.c:1373 gdb_read_memory_packet(): addr: 0x00000000, len: 0x00000001

Debug: 596 266 target.c:1916 target_read_buffer(): reading buffer of 1 byte at 0x00000000

Debug: 597 266 x86_32_common.c:569 x86_32_common_read_memory(): addr=00000000, size=1, count=1, buf=0x1505e30

Error: 598 266 lakemont.c:220 check_not_halted(): target running, halt it first

Error: 599 266 x86_32_common.c:573 x86_32_common_read_memory(): x86_32_common_read_memory invalid params count=1, buf=0x1505e30, addr=00000000

:think:

It seems clear that there are multiple issues. I do have -rtos linux in the target cfg file.

I’m using the recent release of the IOTDK as my tool chain and I’ve tried both the GDB Hardware Debugger plugin and also the other-one-developed-by-I-can’t-remember-who that launches OpenOCD for you. I’ve experimented with various symbol generation and optimization configurations for the build to little (positive) effect. Settled on -g and -O until I get it running.

Any help would really be appreciated.

Thanks,

Dallas

Hello Dallas,

Feel free to ignore this. I haven’t the foggiest what you’re doing, so I can’t help and shouldn’t respond. But my curiosity has gotten the better of me.

When I read your post I get the impression that the Quark is intended to be the target. You say the hardware is mostly working, so I assume I mis-read, and that you’re using the Quark as host. (If you are trying to use openocd with Quark as target I think you’re wasting your time - I’m not aware that openocd has any x86 target support.)

If the Quark is the host, you should probably start by giving some info on what the target is. (This is just my guess - I won’t have the knowledge to help.)

-Hugh