AnsweredAssumed Answered

GDB Linux debugging

Question asked by lukma on Aug 10, 2017
Latest reply on Aug 28, 2017 by Gregchen

Dear All,

 

This question is somewhat connected to: OpenOCD GDB usage issues 

 

However, I've decided to start new thread to avoid mixing topics.

 

The problem is with ADI's BSP (Linux cces-linux-add-in/1.1.0/) gdb and OpenOCD port when working with Linux:

 

1. The ADI BSP's openocd:

sudo /opt/analog/cces/2.6.0/ARM/openocd/bin/openocd -f interface/ice1000.cfg -f target/adspsc58x.cfg
[sudo] password for lukma:
Open On-Chip Debugger (Analog Devices CCES 2.6.0 OpenOCD 0.9.0-g21dc5ad) 0.9.0
Licensed under GNU GPL v2
Report bugs to <processor.tools.support@analog.com>
adapter speed: 1000 kHz

 

Do not support "cortex_a dacrfixup [on|off]", which allows writing breakpoints to .text Linux section.

With Linux one can circumvent this issue with deselecting CONFIG_DEBUG_RODATA in Kconfig.

 

2. When one is able to setup breakpoints another issue shows up:

- Please log into the eval board prompt

- Start openocd (if not already running): sudo /opt/analog/cces/2.6.0/ARM/openocd/bin/openocd -f interface/ice1000.cfg -f target/adspsc58x.cfg

- With GDB: 

(gdb) target remote :3333
Remote debugging using :3333

Program received signal SIGINT, Interrupt.
cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:75
75 ret lr
(gdb)

It seems like we are in a good place (the do_idle function execution is expected)

(gdb) c
Continuing.

 

And here the serial console hangs - no response from the board. The same behaviour is observed for SSH connection.

I can press Ctrl+C and then I do see the "do_idle" function again. However, the console is unresponsive.

 

The openocd output is "clear":

Info : accepting 'gdb' connection on tcp/3333
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000093 pc: 0xc00178c8
MMU: enabled, D-Cache: enabled, I-Cache: enabled
semihosting is enabled

 

 

Can somebody try to reproduce this issue (sc584 + ezbrd devel board + ice1000)?

My goal is to set breakpoint (HW or SW) on sm_send_message_internal @ protocol.c (ICC driver) to inspect the code at some condition.

 

Thanks in advance for support,

Łukasz

Outcomes