Simplify dumping of register lists by only printing cached values
if they are marked as valid. Most of the time, they are invalid;
so printing *any* value is just misleading.
Note that for ARM7 and ARM9 most EmbeddedICE registers (except for
debug status) could be cached most of the time; and their register
cache isn't maintained properly (many accesses seem to bypass that
cache code).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2594 b42882b7-edfa-0310-969c-e2dbd0fdcd60
https://lists.berlios.de/pipermail/openocd-development/2009-August/009939.html
1. It can only be built with the FTD2XX driver. libftdi supports FT2232H/FT4232H
since version 0.16
2. A speed value of 0 is used as a RTCK request indicator. This clashes with the
valid clock division value 0 that provide the highest fixed clock frequency.
3. The ft2232_speed_div function return the maximum selectable frequency (30MHz)
when RTCK is activated. It should return 0.
4. The ft2232_khz function return ERROR_OK when RTCK is requested even for
devices lacking RTCK support. It should return ERROR_FAIL so the upper driver layers
can detect this and try to fallback to a fixed frequency.
5. FT2232H/FT4232H have a backward compatibility function that divide the clock
by 5 to get the same frequency range as FT2232D. There is no code that disable
this functionality. I can not find anything about if this is enabled or disabled by default.
I think it is safest to actively disable it.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2591 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Change jtag_rclk behaviour so it can be called before the interface init function
git-svn-id: svn://svn.berlios.de/openocd/trunk@2590 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- remove endianness options; these chips hard-wire "little"
- $_TARGETNAME updates:
* don't pass $_TARGETNAME where a TAP label is required
* flash config uses $_TARGETNAME (it might not be target #0)
* simplify one $_TARGETNAME construction
- update work area setup:
* remove VM spec; these chips have no VM!
* fix some wrong sizes (0x4000 == 16K, not 4K)
* simplify: take defaults
- comment fixups
git-svn-id: svn://svn.berlios.de/openocd/trunk@2589 b42882b7-edfa-0310-969c-e2dbd0fdcd60
issue with this is that the core debug support uses this
mechanism, then trashes its state over reset. Users can
Work around that (for now) by re-assigning the desired
config after reset.
Also fixes "target halted due to target-not-halted" goof.
When we can't describe the reason using OpenOCD's limited
vocabulary, say "reason undefined" instead of saying it's
not halted.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2588 b42882b7-edfa-0310-969c-e2dbd0fdcd60
arrays (error prone) or assume all registers are 32-bits wide (they can
have fewer bits); don't use spaces in register names, so they can be
passed more easily to the "reg" command.
Minor updates for ARM9 vector_catch support: it's an 8-bit value. This
seems to help this core's vector_catch command work a bit better; but its
behavior wih the register cache is still goofy.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2587 b42882b7-edfa-0310-969c-e2dbd0fdcd60
display them as 32 bits unless that's their true size.
(Removes some confusion.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2586 b42882b7-edfa-0310-969c-e2dbd0fdcd60
OpenOCD was able to access only to chips attached to first EMIF
chipselect. This patch fixes chipselect management code and allows
OpenOCD to access to NAND devices attached to any EMIF CS line.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2585 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add flash programming support for NXP LPC1700 cortex_m3 based family
git-svn-id: svn://svn.berlios.de/openocd/trunk@2579 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Warn about anyone using "jtag_speed" commands; that command is obsolete, and will someday be removed.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2578 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- revert patch from rev1507 as it was causing reset issues with arm9 cores
git-svn-id: svn://svn.berlios.de/openocd/trunk@2574 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.11 Data processing (shifted register)
The usual kinds of problems; the most noteworthy were that
the "S"et flags bit was mis-handled in these instructions.
---
This is the last patch from a quickie set of tests covering all
encodings of the instructions with 32-bit opcodes. There may
be some corner cases left, plus the instructions that aren't
yet handled, but the Thumb2 disassembler is no longer just
"lightly" tested with GCC output ... the new code paths have
mostly been verified.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2568 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.5 Load/store multiple
A5.3.7 Load word
There was a longstanding bug in Thumb-1 LDM; the rest of the LDM/STM
fixes are just using width specs to match UAL syntax, except for two
opcode name typos. Load word had two bitmask goofs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2567 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.8 Load halfword, unallocated memory hints
It's mostly the usual sort of bitmasking goofage and getting the
width specs right. In one case an older x86 GCC generated bad code
unless I structred a conditional differently (sigh).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2566 b42882b7-edfa-0310-969c-e2dbd0fdcd60
A5.3.5 Load/store multiple
A5.3.7 Load word
There was a longstanding bug in Thumb-1 LDM; the rest of the LDM/STM
fixes are just using width specs to match UAL syntax, except for two
opcode name typos. Load word had two bitmask goofs.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2565 b42882b7-edfa-0310-969c-e2dbd0fdcd60
ARMv7-M arch manual:
A5.3.1 Data processing (modified immediate)
A5.3.3 Data processing (plain binary immediate)
A5.3.4 Branches and miscellaneous control
and other (immediate) encodings referenced there. Several of
these just tweak the new syntax ("Unified" ARM/Thumb: UAL) but
there were a few bugs too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2564 b42882b7-edfa-0310-969c-e2dbd0fdcd60
with testcases covering several new encodings in these sections
of the ARMv7-M arch manual:
A5.3.12 Data processing (register)
A5.3.13 Miscellaneous operations
A5.3.14 Multiply, and multiply accumulate
A5.3.15 Long multiply, long multiply accumulate, and divide
The issues were mostly in '12 and '13; some new related 16-bit
opcodes had issues too.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2563 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Dump SP on poll, and show whether it's MSP or PSP.
Thread mode can use either stack pointer, so this is
part of the state that's not yet displayed.
Shrink some lines.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2555 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Clean up treatment of registers in ARMv7-M and Cortex-M3.
- At the arch level:
* Just list registers and names; don't impose core-specific
policy about how they are accessed.
* Each register has a symbol.
* Remove the register mode field (irrelevant to debugger)
- At the core/implementation level:
* Just map the registers to their relevant access methods;
don't require the arch level to say how that should work
(cores other than Cortex-M3 could do it differently).
* Don't use undefined bits from register 20.
* Use register IDs that are part of the ARMv7-M interface.
In short, there's now a real distinction between the arch
and core layers.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2554 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Minor updates to the Thumb2 disassembly:
- Bugfixes:
* Distinguish branch from misc via "!=" not "=="
* MRS register shift is 8 bits (vs MSR being 16)
- Format tweaks:
* CPS needed tab (not space)
* add commma before some shifts
* add space after comma in LDM/STM
* use ".W" width spec on various instructions
git-svn-id: svn://svn.berlios.de/openocd/trunk@2553 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Revert parts of the previous ARMv7-M register patch.
It turns out that part of the issue is a documentation
problem for the Cortex-M3 r1 parts. So for the rest,
simpler fixes are possible (in followup patch).
git-svn-id: svn://svn.berlios.de/openocd/trunk@2552 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- fix issue when multiple flash chips are connected, eg. x16 x 2 on 32bit mcu bus
git-svn-id: svn://svn.berlios.de/openocd/trunk@2551 b42882b7-edfa-0310-969c-e2dbd0fdcd60
ntfreak
oharboe
zwelch