Hi and thanks for working on OpenOCD!
Post by Fewell, EdwardI 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.
OpenOCD architecture is not flexible enough that we can easily support
generic adapters with arbitrary specific optimizations (nor do I think it
should be). We have the "High-Level Adapters"; ST-Link and ICDI that have
similar high level primitives for memory access, except those lack any
low-level operations at all. The support for those adapters exist at the
target layer (!) because that's the best fit. It's a horrible hack and it
makes these adapters unsuitable for low-level debug work. You probably
don't want to go that route and you probably can't if the firmware doesn't
include complete "target-level" operations.
Post by Fewell, EdwardAny 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.
I'm going to have to be a bit skeptical here. Without knowing the details
of what you have done or the XDS110 internals, I don't think you can get
such significant speedup on memory transfers simply by using custom
commands instead of the CMSIS-DAP Transfer commands *when both options are
optimally implemented at both ends*. The CMSIS-DAP protocol itself has very
little overhead for bulk memory access, just 4 or 5 bytes per command which
can be up to 64K transfers. I doubt you can do noticeably better than that
by changing protocol. The MEM-AP overhead is also small since a bulk memory
access is basically just streaming words at least a KiB at a time with a
few register setups in between blocks. AP registers are only updated when
needed by OpenOCD so several smaller accesses do not require significantly
more AP writes than the inevitable transmission of the new address.
If you can actually get 40x speedup (in what sense?), you could potentially
suffer from a bad CMSIS-DAP implementation on either side (OpenOCD is
probably not optimal there) or more likely, be using an entirely different
USB configuration/interface/altsetting with bulk endpoints instead of the
HID mandated interrupt endpoints that kills the potential of the CMSIS-DAP
protocol for no good reason at all.
So I'd guess that the speedup from higher-level memory transaction "smarts"
in the XDS110 FW is a red herring and that the performance gain is more or
less only due to using bulk instead of interrupt transfers. Then, one could
ask, why not simply transport the CMSIS-DAP protocol over the bulk
endpoints instead of using a different protocol. It would fit neatly into
OpenOCD (and other existing debuggers that already speak CMSIS-DAP) with
just a minor change in the low-level USB transport code...
The memory calls within the ARM Cortex architecture code would need to
Post by Fewell, Edwardcheck 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.
What does the memory access fall back to if it's not supported? How are
non-memory access operations implemented? Are the "DAP register calls" also
implemented over the API that provides the memory access functions? What
else does that API provide?
Perhaps if you really wanted to use the probe's memory access functions
(which, if I guess correctly, by themselves won't play a major role in the
performance gains), you could detect memory reads by interpreting the
access pattern of AP registers and transform them to the corresponding
memory accesses.
/Andreas