This is code running on the debug probe’s CPU, not the target. It’s flashed
into the XDS110 as part of its firmware. So the probe has the “smarts” to do
ARM DAP memory transactions directly.
The current software stack issues DAP register accesses to do a memory
transaction (e.g. setting CSW, TAP, SELECT, reading the AP, etc.). The
firmware in our probe does all that for us. So the host side code just needs to
pass in a request like “read 4 bytes from address 0x20000000 on AP #0”, and the
XDS110 does all the work. The result is fewer USB packets needed, and because
this is a full speed USB device, that ends up being a significant performance
boost. This is a low-cost probe. The base CPU chip only has full speed
support. High speed requires external parts not included in most XDS110
implementations. The purpose of this design was something cheap that could be
essentially given away for “free” as part of an evaluation board.
Edward
From: Steven Stallion [mailto:stall...@squareup.com]
Sent: Wednesday, May 31, 2017 8:55 AM
To: Fewell, Edward
Cc: openocd-devel@lists.sourceforge.net
Subject: Re: [OpenOCD-devel] Debug probe hardware that can read/write target
memory directly
Hi Edward,
It sounds like you're describing an algorithm (code that is executed on the
target). Is this something that is resident only when firmware is loaded? Is
this something that's baked into every firmware image or is it copied to RAM
during debugging?
Cheers,
Steve
On Wed, May 31, 2017 at 7:59 AM, Fewell, Edward
<efew...@ti.com<mailto:efew...@ti.com>> wrote:
I am currently implementing the Texas Instruments XDS110 debug probe in
OpenOCD. The firmware of this probe includes APIs to read and write memory via
the target’s DAP for ARM Cortex based devices. The OpenOCD software stack does
not appear to support this and only can execute DAP register transactions via
the probe.
Any ideas on how best to implement this feature from within OpenOCD? The
performance gains are huge for this probe. We see almost 40x improvement
between the CMSIS-DAP interface vs using our built-in memory calls on the
XDS110.
The memory calls within the ARM Cortex architecture code would need to check if
the probe supports direct memory calls then route the call to be handled
entirely by the probe firmware. Otherwise, it could continue on to do the
memory transaction via DAP register calls.
Edward Fewell
Texas Instruments, Inc
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net<mailto:OpenOCD-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/openocd-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
