-
Notifications
You must be signed in to change notification settings - Fork 48
AXS SDP and Ashling GDB Server
Note: the Ashling GDB Server software for ARC is implemented by Ashling and delivered as part of the Ashling Opella-XD probe for ARC processors product. This guide aims to provide all necessary information to successfully debug ARC applications using the GNU toolchain for ARC and the Ashling GDB server, however for all issues related to the Ashling GDB Server application, user should contact Ashling Microsystems Ltd. for further assistance.
Ashling GDB Server can be used to debug application running on the AXS10x family of software development platforms. Users need to use latest version of Ashling drivers and software package available, which, at the moment of this writing, is 1.0.6, however it is known that this version has some problems, which are mentioned in Known Issues section.
To learn how to build applications for AXS SDP, please refer to corresponding section of OpenOCD Wiki page.
Board should be configured the same way as for the OpenOCD. Refer to our wiki guide and to the User Guide of the AXC00x CPU card you are using.
Options of the Ashling GDB Server are described in its User Manual. It is highly recommended that users be familiar with Ashling GDB Server operation before proceeding. In a nutshell, to run GDB Server with multiple cores in the JTAG chain:
$ ./ash-arc-gdb-server --device arc --arc-reg-file <ARC_REG_FILE> \
--scan-file arc2core.xml --tap-number 1,2
That will open GDB server connections on port 2331 (core 1) and 2332 (core 2).
Use GDB to connect to the core you want to debug. <ARC_REG_FILE>
is a path to
a file with AUX register definitions for the core you are going to debug. Due
to recent changes in toolchain, actual file that should be used depends on what
target core is and what toolchain version is being used.
- For toolchain after 2015.06 release files are located in this
toolchain
repository inextras/opella-xd
directory. In this directory there arearc600-cpu.xml
,arc700-cpu.xml
andarc-opella-em.xml
files for GDB server, [direct link] (https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/tree/arc-dev/extras/opella-xd). - For toolchain before 2015.06 release, files for ARC 600 and ARC 700 are shipped with Ashling GDB Server , while file for EM and HS (they share one file) is located [here] (https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/blob/arc-4.8-dev/extras/opella-xd/arc-opella-em.xml)
To run with AXS101 with all four cores in a chain:
$ ./ash-arc-gdb-server --device arc --arc-reg-file <ARC_REG_FILE> \
--scan-file arc4core.xml --tap-number 1,2,3,4
File arc4core.xml
is not shipped with Ashling GDB Server, but can be easily
created after looking at arc2core.xml
and reading Ashling Opella-XD User
Manual.
To run Ashling GDB Server with JTAG chain of a single core:
$ ./ash-arc-gdb-server --device arc --arc-reg-file <ARC_REG_FILE>
Run GDB:
$ arc-elf32-gdb ./application.to.debug
Specify which target core will be debugged with Ashling GDB Server. Actual command depends on toolchain release being used.
For Toolchain starting from 2015.06 release it is required to specify XML
target description file appropriate for the ARC_REG_FILE
used to start
Ashling GDB server. XML target description files for arc600-cpu.xml
,
arc700-cpu.xml
and arc-opella-em.xml
can be found in this toolchain
repository in extras/opella-xd
, direct
link.
It is important that ARC_REG_FILE
for Ashling GDB server and target
description file for GDB match to each other, so if Opella's file has been
modified, so should be target description. Also due to incompatible changes in
GDB, it is required to disable GDB p/P remote packet.
(gdb) set tdesc filename <path/to/opella-CPU-tdesc.xml>
(gdb) set remote P-packet 0
For Toolchain before 2015.06 release instead do this:
(gdb) set arc opella-target <OPELLA_TARGET>
where <OPELLA_TARGET>
is one of arc600
, arc700
or arcem
(EM and HS are
the same in this context).
Further usage is same regardless of Toolchain version used. Connect to the target GDB server:
(gdb) target remote <gdbserver-host>:<port-number>
where <gdbserver-host>
is a hostname/IP-address of the host that runs OpenOCD
(can be omitted if it is localhost), and <port-number>
is a number of port of
the core you want to debug (see previous section).
In most cases you need to load application into the target:
(gdb) load
The system is now ready to debug the application.
To debug several cores on the AXC00x card simultaneously, start additional GDBs and connect to the required TCP ports. Cores are controlled independently from each other.
-
In version of Ashling software up to 1.0.5B, passing option
--tap-number 2
will cause GDB Server to print that it opened connection on port 2331 for core 2, however that is not true, instead GDB Server will create this connection for core 1. Therefore if your JTAG chain contains multiple ARC TAPs you must specify all of them in the argument to--tap-number
option. -
XML register file is specified only once in the GDB Server argument, that means that if your JTAG chain includes multiple cores of different model (e.g. ARC 700 and EM) you cannot debug them simultaneously, but you can debug multiple cores of they same type (e.g. all EM).
-
HS36 core of the AXS102 cannot be used when both cores are in the JTAG chain - if "resume" operation is initiated on the core, GDB Server and GDB will behave like it is running and never halting, but in reality it never started to run. To workaround this issue remove HS34 from the JTAG chain (remove JP1200 jumper on the AXC002 card, remove
--scan-file
and--tap-number
options from Ashling GDB Server command line). If you need both HS34 and HS36 in the JTAG chain use OpenOCD instead of Ashling GDB Server. Why this problem happens is a mystery, since HS36 works without problems when it is single in the JTAG chain, and HS34 always work fine; this is likely a problem with Ashling GDB Server. -
GDB Server prints out those messages when working with ARC EM and ARC HS cores:
Error: Core is running (unexpected), attempting to halt...
Error: Core is running (unexpected), attempting to halt...
Error: Unable to halt core
Despite "Error" status there are no known observable consequences for the the user. Ignore those messages.
- Up to version 1.0.5F there is an error in handling of 4-byte software breakpoints at 2-byte aligned addresses. For example in this sample of code attempt to set breakpoint at 0x2b2 will fail.
0x000002b0 <+0>: push_s blink
0x000002b2 <+2>: st.a fp,[sp,-4]
0x000002b6 <+6>: mov_s fp,sp
0x000002b8 <+8>: sub_s sp,sp,16
-
Big endian ARC v2 cores are not supported on versions prior to 1.0.5-F.
-
In Opella software version of 1.0.6 it has been observed that in some cases target core may hang on application load, if target has external DDR memory attached.
-
In version of 1.0.6 it has been observed that breakpoint set at "main()" function of application may be not hit on first run in HS34 core in AXS102.