Skip to content
Snippets Groups Projects
Select Git revision
  • dw-cmsisdap-path
  • max32xxx default protected
2 results
Search by author
  • Any Author
  • 9R 9R
  • Administrator root
  • Andreas Schildbach pink
  • Daniel Hoffend griffon
  • Definitely Not A Robot Doloo1ai
  • Dirk Jäckel Dirk Jäckel biafra
  • G G
  • Hauke Mehrtens hauke
  • Jan Morawek RFguy
  • Julian hdsjulian
  • Lila Fisch lilafisch
  • Martin Ling martinling
  • Mateusz Zalega msgctl
  • Michael Huebler mh
  • Ole Dreessen ole
  • Phileas Phileas pl
  • Philip Brechler Philip Brechler plaetzchen
  • Renze renze
  • Sabine Wolf Bine
  • Sec 42 sec
20 authors
  1. Oct 27, 2009
  3. Oct 26, 2009
    • David Brownell's avatar
      JTAG: simple autoprobing · 6cb1d10c
      David Brownell authored 
      
This patch adds basic autoprobing support for the JTAG scan chains
which cooperate.  To use, you can invoke OpenOCD with just:

 - interface spec: "-f interface/...cfg"
 - possibly with "-c 'reset_config ...'" for SRST/TRST
 - possibly with "-c 'jtag_khz ...'" for the JTAG clock

Then set up config files matching the reported TAPs.  It doesn't
declare targets ... just TAPs.  So facilities above the JTAG and
SVF/XSVF levels won't be available without a real config; this is
almost purely a way to generate diagnostics.

Autoprobe was successful with most boards I tested, except ones
incorporating C55x DSPs (which don't cooperate with this scheme
for IR length autodetection).  Here's what one multi-TAP chip
reported, with the "Warn:" prefixes removed:

 clock speed 500 kHz
 There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
 AUTO auto0.tap - use "jtag newtap auto0 tap -expected-id 0x2b900f0f ..."
 AUTO auto1.tap - use "jtag newtap auto1 tap -expected-id 0x07926001 ..."
 AUTO auto2.tap - use "jtag newtap auto2 tap -expected-id 0x0b73b02f ..."
 AUTO auto0.tap - use "... -irlen 4"
 AUTO auto1.tap - use "... -irlen 4"
 AUTO auto2.tap - use "... -irlen 6"
 no gdb ports allocated as no target has been specified

The patch tweaks IR setup a bit, so we can represent TAPs with
undeclared IR length.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      6cb1d10c
  5. Oct 25, 2009
  7. Oct 23, 2009
    • David Brownell's avatar
      jtag: clean up TAP state name handling · 79f71fad
      David Brownell authored 
      
Some cosmetic cleanup, and switch to a single table mapping
between state names and symbols (vs two routines which only
share that state with difficulty).

Get rid of TAP_NUM_STATES, and some related knowledge about
how TAP numbers are assigned.  Later on, this will help us
get rid of more such hardwired knowlege.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      79f71fad
    • David Brownell's avatar
      SVF: clean up, mostly for TAP state name handling · 814183a5
      David Brownell authored 
      
 - Use the name mappings all the other code uses:
    + name-to-state ... needed to add one special case
    + state-to-name
 - Improve various diagnostics:
    + don't complain about a "valid" state when the issue
      is actually that it must be "stable"
    + say which command was affected
 - Misc:
    + make more private data and code be static
    + use public DIM() not private dimof()
    + shorten the affected lines

Re the mappings, this means we're more generous in inputs we
accept, since case won't matter.  Also our output diagnostics
will be a smidgeon more informative, saying "RUN/IDLE" not
just "IDLE" (emphasizing that there can be side effects).

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      814183a5
  9. Oct 21, 2009
    • David Brownell's avatar
      XSVF: use svf_add_statemove() · 7556a93a
      David Brownell authored 
      
XSVF improvements:

 - Layer parts of XSVF directly over SVF, calling svf_add_statemove()
   instead of expecting jtag_add_statemove() to conform to the SVF/XSVF
   requirements (which it doesn't).

   This should improve XSTATE handling a lot; it removes most users of
   jtag_add_statemove(), and the comments about how it should really do
   what svf_add_statemove() does.

 - Update XSTATE logic to be a closer match to the XSVF spec.  The main
   open issue here is (still) that this implementation doesn't know how
   to build and submit paths from single-state transitions ... but now
   it will report that error case.

 - Update the User's Guide to mention the two utility scripts for
   working with XSVF, and to mention the five extension opcodes.

Handling of state transition paths is, overall, still a mess.  I think
they should all be specified as paths not unlike SVF uses, and compiled
to the bitstrings later ... so that we can actually make sense of the
paths.  (And see the extra clocks, detours through RUN, etc.)

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      7556a93a
  11. Oct 20, 2009
  13. Oct 19, 2009
  15. Oct 15, 2009
  17. Oct 13, 2009
  19. Oct 10, 2009
  21. Oct 09, 2009
  23. Oct 08, 2009
    • David Brownell's avatar
      prevent abort via polling during jtag_reset · a8234af0
      David Brownell authored 
      
Observed:

  openocd: core.c:318: jtag_checks: Assertion `jtag_trst == 0' failed.

The issue was that nothing disabled background polling during calls
from the TCL shell to "jtag_reset 1 1".  Fix by moving the existing
poll-disable mechanism to the JTAG layer where it belongs, and then
augmenting it to always pay attention to TRST and SRST.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      a8234af0
    • David Brownell's avatar
      Stop ignoring most scan chain validation errors · 40c9668b
      David Brownell authored 
      
Among other things this causes startup errors to kick in the
fallback "reset harder" logic during server startup.  Comments
are also updated a bit, explaining what the various error paths
signify (in at least my observation).

There's one class of validation error that we can still plausibly
ignore:  when wrong IDCODE values are observed.

This change seems to have helped make an OMAP5912 behave much
more reliably.  There's still some post-reset flakiness, but
it's unrelated to scan verification.

Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      40c9668b
  25. Oct 07, 2009
  27. Oct 06, 2009
  29. Oct 05, 2009
    • dbrownell's avatar
      Improve jtag_validate_ircapture() diagnostics. · 7a57c316
      dbrownell authored 
      Bugfix the error message so it shows the disliked value, and add
a debug message showing each TAP's IR capture value, all N bits.

This just changes diagnostics ... it still ignores the parameters
given to us at TAP declaration time.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2801 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7a57c316
    • dbrownell's avatar
      Add a new JTAG "setup" event; use for better DaVinci ICEpick support. · 7c7467b3
      dbrownell authored 
      The model is that this fires after scanchain verification, when it's
safe to call "jtag tapenable $TAPNAME".  So it will fire as part of
non-error paths of "init" and "reset" command processing.  However it
will *NOT* trigger during "jtag_reset" processing, which skips all
scan chain verification, or after verification errors.

ALSO:
 - switch DaVinci chips to use this new mechanism
 - log TAP activation/deactivation, since their IDCODEs aren't verified
 - unify "enum jtag_event" scripted event notifications
 - remove duplicative JTAG_TAP_EVENT_POST_RESET


git-svn-id: svn://svn.berlios.de/openocd/trunk@2800 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7c7467b3
  31. Sep 29, 2009
  33. Sep 28, 2009
  35. Sep 27, 2009
    • dbrownell's avatar
      Update FT2232 driver so that it reliably enters TAP_RESET. · 817ea3f4
      dbrownell authored 
      When the OpenOCD server starts up it records its state as TAP_RESET,
even though it could be anything.  Then when it starts to examine
the scan chain, it calls jtag_add_tlr() which sees it doesn't have
any work to do, and so it does nothing.  This can make the next
operations fail because they start from the wrong TAP state...

Instead of caring about the current recorded state, always enter
TAP_RESET by forcing five clocks with TMS high.

(NOTE:  it seems most other JTAG adapter drivers have this same bug.)


git-svn-id: svn://svn.berlios.de/openocd/trunk@2763 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      817ea3f4
  37. Sep 26, 2009
  39. Sep 21, 2009
  41. Sep 20, 2009
    • dbrownell's avatar
      Debug message updates: · 0c4b119d
      dbrownell authored 
       - Shrink messaging during resets, primarily by getting rid of
   "nothing happened" noise that hides *useful* information.

 - Improve: the "no IDCODE" message by identifying which tap only
   supports BYPASS; and the TAP event strings.

Related minor code updates:

 - Remove two needless tests when examining the chain:  we know
   we have a TAP, and that all TAPs have names.

 - Clean up two loops, turning "while"s into "for"s which better
   show what's actually being done.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2736 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      0c4b119d
    • dbrownell's avatar
      Minor regression bugfix for the jtag_tap_handle_event() case · 75581ffe
      dbrownell authored 
      for disabling TAPs.  We don't actually know how to make any
JRCs which do that yet; but when we do, this will matter.


git-svn-id: svn://svn.berlios.de/openocd/trunk@2735 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      75581ffe
  43. Sep 19, 2009