Via code review by Steve Grubb <sgrubb@redhat.com>
Almost innocuous; this is value is checked later, this
check being wrong would make it check stack garbage.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2655 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Via code review by Steve Grubb <sgrubb@redhat.com>
Also minor fixes for the message from "fill": the byte
count is unsigned, not signed; and more importantly,
print the real number of bytes written
git-svn-id: svn://svn.berlios.de/openocd/trunk@2652 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Itemize the list of private customization examples
for openocd.cfg
- Add "override defaults" as a customization, specifically
for the work area (back it up or relocate it)
- Highlight some work area location issues
git-svn-id: svn://svn.berlios.de/openocd/trunk@2651 b42882b7-edfa-0310-969c-e2dbd0fdcd60
on the command line ... matching comment in add_default_dirs().
Without this it's impossible to use a private config file which
happens to have the same name as an installed one. Say, because
you're bugfixing a private copy...
git-svn-id: svn://svn.berlios.de/openocd/trunk@2649 b42882b7-edfa-0310-969c-e2dbd0fdcd60
defining ntrst_delay is pointless; don't.
At least the LM3S3748 eval board doesn't need nsrst_delay
either; remove that too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2645 b42882b7-edfa-0310-969c-e2dbd0fdcd60
that were added after ARMv5TE was defined:
- ARMv5J "BXJ" (for Java/Jazelle)
- ARMv6 "media" instructions (for OMAP2420, i.MX31, etc)
Compile-tested. This might not set up the simulator right for the
ARMv6 single step support; only BXJ branches though, and docs to
support Jazelle branching are non-public (still, sigh).
ARMv6 instructions known to be mis-handled by this disassembler
include: UMAAL, LDREX, STREX, CPS, SETEND, RFE, SRS, MCRR2, MRRC2
git-svn-id: svn://svn.berlios.de/openocd/trunk@2644 b42882b7-edfa-0310-969c-e2dbd0fdcd60
With DCCR we are asking the CPU to halt, we should wait until
the CPU has halted before proceeding with the operation.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2638 b42882b7-edfa-0310-969c-e2dbd0fdcd60
the ITR register but it will only be executed when the DSCR[13]
bit is set. The documentation is a bit weird as it classifies
the DSCR as read-only but the pseudo code is writing to it as
well. This is working on a beagleboard.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2634 b42882b7-edfa-0310-969c-e2dbd0fdcd60
instruction to be finished. This comes from the pseudo code
of the cortex a8 trm.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2632 b42882b7-edfa-0310-969c-e2dbd0fdcd60
"next iteration" step with the rest of the loop overhead.
Cleanup: remove spurious whitespace, and an overlong line;
only assign "tap->hasidcode" once.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2631 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Bugfixes:
* internal osc: it's *12* MHz (not 15 MHz) on _current_ chips
+ except new Tempest parts where it's 16 MHz (and calibrated!)
+ or some old Sandstorm ones, where 15 MHz was valid
* crystal config:
+ read and use the crystal config, don't assume 6 MHz
+ know when that field is 4 bits vs 5
* an RCC2 register may be overriding the original RCC
+ more clock source options
+ bigger dividers
+ fractional dividers on Tempest (NYET handled)
* there's a 30 KHz osc on newer chips (for deep sleep)
* there's a 32768 Hz osc on newer chips (for hibernation)
- Cosmetic
* say "rev A0" not "vA.0", to match vendor docs
* don't always report master clock as an "estimate":
+ give the error bound if it's approximate, like "±30%"
+ else don't say anything
* fix whitespace and caps in some messages
* these are not AT91SAM chips!!
Those clock issues might explain problems sometimes reported when
writing to Stellaris flash banks; they affect write timings.
That 12-vs-15 MHz issue is problematic; there's no consolidated doc
showing which chips (and revs!) have which internal oscillator speed.
It's clear that only older silicon had the faster-and-less-accurate
flavor. What's less clear is which chips are "old" like that.
Lightly tested, on a DustDevil part.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2626 b42882b7-edfa-0310-969c-e2dbd0fdcd60
For ARMv4/ARMv5:
- better command parameter error checking
- don't require an instruction count; default to one
- recognize thumb function addresses
- make function static
- shorten some too-long lines
For Cortex-M3:
- don't require an instruction count; default to one
With the relevant doc updates.
---
Nyet done: invoke the thumb2 disassembler on v4/v5,
to better handle branch instructions.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2624 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Unify the handling of the req_srst parameter, and rip out a
large NOP branch and its associated FIXME. (There didn't seem
to be anything that needs fixing; but that was unclear since
the constraints were scattered all over the place not unified.)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2623 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Unify the handling of the req_tlr_or_trst parameter. Basically,
JTAG TMS+TCK ops ("TLR") is always used ... unless TRST is a safe
option in this system configuration.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2622 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- Track whether TRST and/or SRST actually change:
* If they're not changing, don't ask the JTAG adapter to do anything!
(JTAG TCK/TMS ops might still be used to enter TAP_RESET though.)
* Don't change their recorded values until after the adapter says it
did so ... so fault paths can't leave corrupt state.
* Detect and report jtag_execute_queue() failure mode
* Only emit messages saying what really changed; this includes adding
an omitted "deasserted TRST" message.
* Only apply delays after deasserting SRST/TRST if we *DID* deassert!
- Messages say "TLR" not "RESET", to be less confusing; there are many
kinds of reset. (Though "TLR" isn't quite ideal either, since it's
the name of the TAP state being entered by TMS+TCK or TRST; it's at
least non-ambiguous in context.)
So the main effect is to do only the work this routine was told to do;
and to have debug messaging make more sense.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2621 b42882b7-edfa-0310-969c-e2dbd0fdcd60
reset operations. Maybe they can't; or it's a "not yet" thing.
Note that the assert/deassert operations can't yet trigger for
OMAP3 because resets currently include JTAG reset in all cases,
resetting the ICEpick and thus disabling the TAP for Cortex-A8.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2620 b42882b7-edfa-0310-969c-e2dbd0fdcd60
the values that are written in the mini-IC (plus documentation updates that
describe why this is needed).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2613 b42882b7-edfa-0310-969c-e2dbd0fdcd60
