1. 06 Oct, 2009 1 commit
  2. 05 Oct, 2009 1 commit
    • 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
  3. 29 Sep, 2009 1 commit
  4. 26 Sep, 2009 1 commit
    • dbrownell's avatar
      Streamline Capture-IR handling and integrity test. · 2e210ee4
      dbrownell authored
      Change the handling of the "-ircapture" and "-irmask" parameters
      to be slightly more sensible, given that the JTAG spec describes
      what is required, and that we already require that conformance in
      one place.  IR scan returns some bitstring with LSBs "01".
      
       - First, provide and use default values that satisfy the IEEE spec.
         Existing TAP configs will override the defaults, but those parms
         are no longer required.
      
       - Second, warn if any TAP gets set up to violate the JTAG spec.
         It's likely a bug, but maybe not; else this should be an error.
         Improve the related diagnostics to say which TAP is affected.
      
      And associated minor fixes/cleanups to comments and diagnostics.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2758 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      2e210ee4
  5. 20 Sep, 2009 2 commits
    • 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
  6. 17 Sep, 2009 2 commits
  7. 11 Sep, 2009 1 commit
  8. 09 Sep, 2009 1 commit
  9. 24 Aug, 2009 1 commit
  10. 18 Aug, 2009 1 commit
  11. 07 Aug, 2009 1 commit
  12. 17 Jul, 2009 1 commit
  13. 07 Jul, 2009 1 commit
  14. 30 Jun, 2009 1 commit
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 0894ae21
      zwelch authored
      Add "jtag names" command, mirroring "target names" but returning
      TAP names instead of target names.  This starts letting TAPs be
      manipulated in scripts ... much like what works now for targets.
      
      It's a bit limited just yet, since "jtag cget $TAPNAME" doesn't
      expose all TAP attributes.  "$TARGETNAME cget" is more functional.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2428 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      0894ae21
  15. 29 Jun, 2009 1 commit
  16. 23 Jun, 2009 14 commits
  17. 19 Jun, 2009 2 commits
  18. 18 Jun, 2009 1 commit
  19. 17 Jun, 2009 1 commit
  20. 16 Jun, 2009 5 commits
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · c928fe0f
      zwelch authored
      Fix a bug preventing ICEpick "enable that TAP" code from working:
      the "runtest" command wrongly finished with a JTAG reset, discarding
      the work the TAP enable handler just finished!  Instead, JTAG should
      stay in RUN/IDLE state.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2252 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      c928fe0f
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · a0c10dd2
      zwelch authored
      Extend the internal JTAG event handlers to cover enable/disable,
      and use those events to make sure that targets get "examined" if
      they were disabled when the scan chain was first set up:
      
       - Remove "enum jtag_tap_event", merge with "enum jtag_event",
         so C code can now listen for TAP enable/disable events.
      
       - Report those events so they can trigger callbacks.
      
       - During startup, make target_examine() register a handler to
         catch ENABLE events for any then-disabled targets.
      
      This fixes bugs like "can't halt target after enabling its TAP".
      
      One class of unresolved bugs:  if the target has an ETM hooked
      up to an ETB, nothing activates the ETB.  But starting up the
      ETM without access to the ETB registers fails...
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2251 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a0c10dd2
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 491083a2
      zwelch authored
      Tighten error handling on TAP enable/disable paths a bit:
      
       - Don't enable/disable unless it's necessary.  Those event
         handlers could have nasty side effects...
      
       - Don't *succeed* enables/disables if there was no code which
         could have implemented that action.  This prevents bugs like
         wrongly acting as if the scan chain changed.
      
       - Minor whitespace cleanup in enable/disable command code.
      
      The big problem is still the lack of code to verify scan chains
      were actually updated as requested; this adds a comment on that.
      I suspect the best we can do near term will be to verify IDCODE.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2250 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      491083a2
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 0de47861
      zwelch authored
      Fix bug in a warning.  It warned about "huge IRlength" for an
      older JRC with a two bit instruction register ... wrong!
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2249 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      0de47861
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 5f9b74d0
      zwelch authored
      Doc update:  say "jtag newtap ... -disable" records the
      state after exiting the RESET state, matching the only
      implementation we're working with so far (TI ICEpick-C).
      
      Matching code updates.  Now we can be sure that the
      "enabled" flag value is correct after JTAG resets.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2246 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      5f9b74d0