Skip to content
Snippets Groups Projects
  1. Jun 17, 2009
  2. Jun 16, 2009
    • 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>: · 14f88aca
      zwelch authored
      Fix some polling issues:
      
       - Don't background-poll disabled TAPs ... this was just a bug
         waiting to happen.  (And then it happened!)
      
       - Don't fail command line polls of disabled taps; that's not any
         kind of error, it's just that you can't do much.  But do show
         that tap-disabled status.
      
       - Spell "continuous" correctly in the variable name.  ;)
      
      Not resolved by this patch:  the need for an interlock whereby
      other code (like the JTAG layer) can block all other access to
      the JTAG layer, e.g. while enabling or disabling TAPs.  And
      that interlock needs to be timer-safe...
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2247 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      14f88aca
    • 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
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 03803a9d
      zwelch authored
      Fix a memory leak in jtag_tap_free():  unregister the event
      callback too.
      
      Also fix the associated conceptual bug in unregistering JTAG
      event callbacks:  since the same callback procedure is used
      many times with different callback data (a TAP handle), that
      data must be considered when unregistering any callback.
      
      This could fix some crashes after TAP registration errors,
      by making sure the reset event handler doesn't scribble over
      memory that's now used by something else.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2245 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      03803a9d
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · c7cfb341
      zwelch authored
      Minor jtag cleanup:
      
       - remove hidden assumption about JTAG event numbering
       - move function declarations to a header
       - some end'o'line whitespace
       - use "calloc" not "malloc + memset"
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2244 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      c7cfb341
  3. Jun 15, 2009
  4. Jun 13, 2009
  5. Jun 12, 2009
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · cdd8f23b
      zwelch authored
      Currently the "debug_level 3" command tracing ignores commands
      that could return values to TCL scripts (by plugging in to a
      slightly lower level of the interpreter stack).
      
      Fix that by abstracting the tracing command and starting to
      make some of those previously-untraced commands use this new
      mechanism.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2224 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      cdd8f23b
    • zwelch's avatar
      David Brownell <david-b@pacbell.net>: · 8551803e
      zwelch authored
      Partial fix to the "long IR length" problems.
      
       - Current code could handle up to 32 bit IR lengths with
         full functionality, if it didn't just reject may of them
         out of hand.  So only reject clear errors, where the IR
         mask (or capture instruction) needs more than IrLen bits.
      
       - Longer IR lengths can only be handled in BYPASS mode
         for now.  Example:  TI's DSPs use 38-bit IR lengths.
         So we can't issue their IDCODE instructions...
      
      A more complete fix would be able to issue longer instructions;
      or minimally, would fail cleanly for the non-BYPASS case.
      
      Note that this *could* make some currently broken scripts fail,
      since the previous code accepted garbage values so long as
      they didn't use more than 16 bits.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2222 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      8551803e
    • zwelch's avatar
      unsik Kim <donari75@gmail.com>: · a92cc405
      zwelch authored
      Improve error handling in mflash driver.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2221 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      a92cc405
    • zwelch's avatar
      Further cleanup to MIPS target read/write memory function: · 7fdce0e8
      zwelch authored
      - Move the mips32_..._read_mem calls to top-level of read_mem function.
      - Change: Only perform mips_m4k_read_mem conversion when retval == ERROR_OK.  
         - Prevents pointless conversions of bogus read values after failures.
      - Eliminate retval variable from mips_m4k_write_mem; return directly.
      - Move declaration of retval variable to point of first use.
      - Remove the now redundant switch statements testing size:
        - argument sanitizing already covers these cases.
      
      
      git-svn-id: svn://svn.berlios.de/openocd/trunk@2220 b42882b7-edfa-0310-969c-e2dbd0fdcd60
      7fdce0e8
Loading