JEDEC standard reports Vpp integer part encoded as 4 bit HEX value.
To print it using decimal digits, %u is required.
Other voltage values are coded as BCD, so %x is appropriate.
Code already prints one nibble at a time, so no need for field width
and precision in format string.
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
Talk more about "debug adapters" instead of only "dongles". Not all
adapters are discrete widgets; some are integrated onto boards. If
we only talk about "dongles" we rule out many valid setups, and help
confuse some users (who may be using Dongle-free environments).
Also start bringing out the point that JTAG isn't the only transport
protocol, even though OpenOCD historically presumes "all is JTAG".
(Not all debug adapters are JTAG adapters, or JTAG-only adapters.)
Plus a few minor fixes (spelling etc) in the vicinity of those changes,
and updates about FT2232H clocking issues (they can go faster than the
older chips, and can support adaptive clocking).
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The FT2232H really wants libftdi 0.17 or newer; some notable
bugs got fixed in that version.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Get rid of needless and undesirable code duplication for
all the DAP commands (resolving a FIXME) ... there's no
need for coreas to have private copies of that stuff.
Stick a pointer to the DAP in "struct arm", letting common
code get to it.
Also rename the "swjdp_info" symbol; just call it "dap".
This is an overall code shrink.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
This partially corrects an inappropriate name choice (and its
associated FIXME).
There are still too many variables named "swjdp", bug little
current code actually relies on them referencing an SWJ-DP instead
of some other flavor of DAP. Only the two new dap_to{swd,jtag}()
calls could behave differently on an SWJ-DP instead of a SW-DP or
a JTAG-DP.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
When the beginning or end of the specified range of sectors
already has the requested protection status, don't ask the
flash driver to change those sectors.
This will among other things turn command sequences like
this into the NOPs one would expect:
flash protect_check 0
flash info 0
... reports everything as unprotected ...
flash protect 0 0 1 off
That speeds things up (by whatever work was just avoided).
Also, with Stellaris (which can't unprotect flash at page level)
this can eliminate some undesirable/false error reports. (And
finishes fixing a bug currently listed in our bug database...)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The NOR infrastructure caches some per-sector state, but
it's not used much ... because the cache is not trustworthy.
This patch addresses one part of that problem, by ensuring
that state cached by NOR drivers gets invalidated once we
resume the target -- since targets may then modify sectors.
Now if we see sector protection or erase status marked as
anything other than "unknown", we should be able to rely
on that as being accurate. (That is ... if we assume the
drivers initialize and update this state correctly.)
Another part of that problem is that the cached state isn't
much used (being unreliable, it would have been unsafe).
Those issues can be addressed in later patches.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Give a more accurate failure message when trying to unprotect; don't
complain about pages being write protected, just say that unprotect is
not supported by the hardware ... referencing the new "recover" command,
which is the way to achieve that.
Likewise, when trying to protect, talk about "pages" (matching hardware
doc) not "sectors" (an concept that's alien to these chips).
Also make the helptext for the "recover" command mention that it
also erases the device.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make ADIv5 internals use the two new transport-neutral calls for reading
and writing DP registers; and do the same for external callers. Also,
bugfix some of their call sites to handle the fault returns, instead of
ignoring them.
Remove most of the JTAG-specific calls, using their code as the bodies
of the JTAG-specific implementation for the new methods.
NOTE that there's a remaining issue: mem_ap_read_buf_u32() makes calls
which are JTAG-specific. A later patch will need to remove those, so
JTAG-specific operations can be removed from this file, and so that SWD
support will be able to properly drop in as just a transport layer to the
ADIv5 infrastructure. (The way read results are posted may need some more
attention in the transport-neutrality interface.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make ADIv5 internals use the two new transport-neutral calls for reading
and writing DP registers. Also, bugfix some of their call sites to
handle the fault returns, instead of ignoring them.
Remove the old JTAG-specific calls, using their code as the bodies
of the JTAG-specific implementation for the new methods.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Make ADIv5 use one of the new transport-neutral interfaces: call
dap_run(), not jtagdp_transaction_endcheck().
Also, make that old interface private; and bugfix some of its call
sites to handle the fault returns, instead of ignoring them.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
To support both JTAG and SWD, ADIv5 needs DAP operations which are
transport-neutral, instead being of JTAG-specific. This patch:
- Defines such a transport-neutral interface, abstracting access
to DP and AP registers through a conceptual queue of operations.
- Builds the first implementation of such a transport with the existing
JTAG-specific code.
In contrast to the current JTAG-only interface, the interface adds
support for two previously-missing (and unused) DAP operations:
- aborting the current AP transaction (untested);
- reading the IDCODE register (tested) ... required for SWD init.
The choice of transports may be fixed at the chip, board, or JTAG/SWD
adapter level. Or if all the relevant hardware supports both transport
options, the choice may be made at runtime, This patch provides basic
infrastructure to support whichever choice is made.
The current "JTAG-only" transport choice policy will necessarily continue
for now, until SWD support becomes available in OpenOCD. Later patches
start phasing out JTAG-specific calls in favor of transport-neutral calls.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add doxygen for target_resume() ... referencing the still-unresolved
confusion about what the "debug_execution" parameter means (not all
CPU support code acts the same).
The 'handle_breakpoints" param seems to have resolved the main issue
with its semantics, but it wasn't part of the function spec before.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Fix some issues with the generic LPC1768 config file:
- Handle the post-reset clock config: 4 MHz internal RC, no PLL.
This affects flash and JTAG clocking.
- Remove JTAG adapter config; they don't all support trst_and_srst
- Remove the rest of the bogus "reset-init" event handler.
- Allow explicit CCLK configuration, instead of assuming 12 MHz;
some boards will use 100 Mhz (or the post-reset 4 MHz).
- Simplify: rely on defaults for endianness and IR-Capture value
- Update some comments too
Build on those fixes to make a trivial config for the IAR LPC1768
kickstart board (by Olimex) start working.
Also, add doxygen to the lpc2000 flash driver, primarily to note a
configuration problem with driver: it wrongly assumes the core clock
rate never changes. Configs that are safe for updating flash after
"reset halt" will thus often be unsafe later ... e.g. for LPC1768,
after switching to use PLL0 at 100 MHz.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Correct a mistake made copying the ID of the Cortex-M3 ETM module
from the TRM, so that "dap info" on a CM3 with an ETM will now
correctly describe ROM table entries for such modules. (They are
included on LPC17xx and some other cores.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
The recent "add armv7m semihosting support" patch introduced two
build errors:
arm_semihosting.c: In function ‘do_semihosting’:
arm_semihosting.c:71: error: ‘spsr’ may be used uninitialized in this function
arm_semihosting.c:71: error: ‘lr’ may be used uninitialized in this function
This fixes those build errors. The behavior is, however, untested.
(Also, note the two new REVISIT comments.)
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
after clocking out a tms sequence, then the TAP will be
in some state. This state is now handed to the drivers.
TAP_INVALID is a possible state after a TMS sequence if
switching to SWD.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
core_type check is not required as the core function will be
null for cores that do not support the mcr/mrc functions.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
windows api does not define a posix sleep, use usleep that
has an openocd wrapper to the win32 native function.
Signed-off-by: Spencer Oliver <ntfreak@users.sourceforge.net>
