1. 18 Jun, 2009 18 commits
  2. 17 Jun, 2009 17 commits
  3. 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
    • 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
    • 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
    • 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
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 011e9b85
      zwelch authored
      Distributing FTDI's "ftd2xx" library with OpenOCD violates the
      OpenOCD license (GNU GPLv2 with no exceptions).
      Make that clear where that build option is presented, and don't
      describe the FTDI libraries as an option for any packager.  (It's
      fine for personal use, of course.)
      Plus some related clarifications:  libftdi version 0.16 for the
      new FT2232H chips (for RTCK and high speed USB); the Amontec
      drivers are just ftd2xx variants.
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2248 b42882b7-edfa-0310-969c-e2dbd0fdcd60