1. 17 Apr, 2019 3 commits
  2. 11 Jan, 2019 1 commit
  3. 21 Aug, 2018 1 commit
  4. 23 Jul, 2018 1 commit
  5. 18 Jul, 2018 1 commit
    • Edward Fewell's avatar
      flash/nor: add support for TI MSP432 devices · 3e84da55
      Edward Fewell authored
      Added msp432 flash driver to support the TI MSP432P4x and
      MSP432E4x microcontrollers. Implemented the flash algo
      helper as used in the TI debug and flash tools. This
      implemention supports the MSP432E4, Falcon, and Falcon 2M
      variants. The flash driver automatically detects the
      connected variant and configures itself appropriately.
      Added command to mass erase device for consistency with
      TI tools and added command to unlock the protected BSL
      Tested using MSP432E401Y, MSP432P401R, and MSP432P4111
      Tested with embedded XDS110 debug probe in CMSIS-DAP
      mode and with external SEGGER J-Link probe.
      Removed ti_msp432p4xx.cfg file made obsolete by this
      Change-Id: I3b29d39ccc492524ef2c4a1733f7f9942c2684c0
      Signed-off-by: default avatarEdward Fewell <efewell@ti.com>
      Reviewed-on: http://openocd.zylin.com/4153
      Tested-by: jenkins
      Reviewed-by: default avatarMatthias Welwarsky <matthias@welwarsky.de>
      Reviewed-by: default avatarTomas Vanek <vanekt@fbl.cz>
  6. 15 Jun, 2018 1 commit
  7. 06 Jun, 2018 1 commit
    • Edward Fewell's avatar
      flash/nor: Add support for TI CC3220SF internal flash · d02de3a8
      Edward Fewell authored
      Added cc3220sf flash driver to support the TI CC3220SF
      microcontrollers. Implemented flash driver to support the
      internal flash of the CC3220SF. The implementation does not
      support the serial flash of the CC32xx family that requires
      connection over UART, and not via JTAG/SWD debug. Added config
      files for both CC32xx devices (no flash) and CC3220SF (with
      Updated to implement comments from code review.
      Additional updates to handle remaining comments from review.
      Additional updates per review.
      Added code to only request aligned writes and full 32-bit
      words down to flash helper algorithm. Updated for recent
      changes in OpenOCD flash code.
      Removed cc32xx.cfg file made obsolete by this patch.
      Change-Id: I58fc1478d07238d39c7ef02339f1097a91668c47
      Signed-off-by: default avatarEdward Fewell <efewell@ti.com>
      Reviewed-on: http://openocd.zylin.com/4319
      Tested-by: jenkins
      Reviewed-by: default avatarTomas Vanek <vanekt@fbl.cz>
  8. 23 Apr, 2018 1 commit
  9. 10 Apr, 2018 1 commit
    • Tomas Vanek's avatar
      target armv7m: multi-block erase check · a867e36f
      Tomas Vanek authored
      Tested on PSoC6 (Cortex-M0+ core), onboard KitProg2 in CMSIS-DAP mode,
      Plain read:
      	flash read_bank 0 /dev/null
      takes 48 seconds.
      erase_check without this change:
      	flash erase_check 0
      takes horrible 149 seconds!!
      And the same command with the change applied takes 1.8 seconds.
      Quite a difference.
      Remove the erase-value=0 version of algorithm as the new one can check
      for any value.
      If the target is an insane slow clocked CPU (under 1MHz) algo
      timeouts. Blocks checked so far are returned and the next call
      uses increased timeout.
      Change-Id: Ic0899011256d2114112e67c0b51fab4f6230d9cd
      Signed-off-by: default avatarTomas Vanek <vanekt@fbl.cz>
      Reviewed-on: http://openocd.zylin.com/4298
      Tested-by: jenkins
      Reviewed-by: default avatarJonas Norling <jonas.norling@cyanconnode.com>
      Reviewed-by: default avatarAndreas Bolsch <hyphen0break@gmail.com>
  10. 07 Mar, 2018 1 commit
  11. 13 Jan, 2018 1 commit
    • Robert Jordens's avatar
      jtagspi: new protocol that includes transfer length · 867bdb2e
      Robert Jordens authored
      This commit contains a rewrite of the jtagspi protocol and covers both
      changes in the jtagspi.c openocd driver and the bscan_spi
      (xilinx_bscan_spi) proxy bitstreams. The changes are as follows:
      1. Always perform IR scan to ensure proper clearing of BYPASSed DRs.
      2. Insert alignment cycles for all BYPASSed TAPs:
        The previous logic was erroneous. The delay in clock cyles from a bit
        written to the jtag interface to a bit read by the jtag interface is:
        * The number of BYPASSed TAPs before this (jtagspi) tap
        * The length of the jtagspi data register (1)
        * The number of BYPASSed TAPs before this one.
        I.e. it is just the number of enabled TAPs. This also gets rid of the
        configuration parameter DR_LENGTH.
      3. Use marker bit to start spi transfer
        If there are TAPs ahead of this one on the JTAG chain, and we are in
        DR-SHIFT, there will be old bits toggled through first before the first
        valid bit destined for the flash.
        This delays the begin of the JTAGSPI transaction until the first high bit.
      4. New jtagspi protocol
        A JTAGSPI transfer now consists of:
        * an arbitrary number of 0 bits (from BYPASS registers in front of the
          JTAG2SPI DR)
        * a marker bit (1) indicating the start of the JTAG2SPI transaction
        * 32 bits (big endian) describing the length of the SPI transaction
        * a number of SPI clock cycles (corresponding to 3.) with CS_N asserted
        * an arbitrary number of cycles (to shift MISO/TDO data through
          subsequent BYPASS registers)
      5. xilinx_bscan_spi: clean up, add ultrascale
      This is tested on the following configurations:
      * KC705: XC7K325T
      * Sayma AMC: XCKU040
      * Sayma AMC + RTM): XCKU040 + XC7A15T, a board with integrated FTDI JTAG
        adapter, SCANSTA JTAG router, a Xilinx Ultrascale XCKU040 and a Xilinx
        Artix 7 15T. https://github.com/m-labs/sinara/wiki/Sayma
      * Custom board with Lattice FPGA + XC7A35T
      * CUstom board with 3x XCKU115-2FLVA1517E
      Change-Id: I7361e9fb284ebb916302941735eebef3612aa103
      Signed-off-by: default avatarRobert Jordens <jordens@gmail.com>
      Reviewed-on: http://openocd.zylin.com/4236
      Tested-by: jenkins
      Reviewed-by: default avatarPaul Fertser <fercerpav@gmail.com>
  12. 07 Dec, 2017 1 commit
  13. 06 Dec, 2017 1 commit
  14. 03 Oct, 2017 1 commit
  15. 17 Jun, 2017 1 commit
  16. 24 Apr, 2017 1 commit
  17. 08 Dec, 2016 1 commit
  18. 04 Nov, 2016 1 commit
  19. 04 Oct, 2016 1 commit
  20. 14 Aug, 2016 1 commit
  21. 13 Aug, 2016 2 commits
  22. 22 May, 2016 3 commits
  23. 20 May, 2016 1 commit
  24. 05 May, 2016 2 commits
  25. 04 May, 2016 4 commits
  26. 29 Feb, 2016 3 commits
    • Andreas Färber's avatar
      armv7m: Integrate build of erase check code · c3c15d2e
      Andreas Färber authored
      Instead of documenting the file path as a comment and inline-commenting
      the THUMB bytecode, include the hex array via preprocessor.
      This assures the path is actually up-to-date and facilitates updating
      the code.
      Change-Id: Ieb0a7cd0bc14882ac96750f524616d9768a0c6f5
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-on: http://openocd.zylin.com/3134
      Tested-by: jenkins
      Reviewed-by: default avatarAndreas Fritiofson <andreas.fritiofson@gmail.com>
    • Andreas Färber's avatar
      xmc4xxx: Integrate build of erase check code · 7cf68a0f
      Andreas Färber authored
      Instead of pointing to the assembler sources in a comment and
      inline-commenting the THUMB bytecode, place the hex array alongside the
      assembler sources and include it via preprocessor.
      Originally inspired by a typo in the file path during driver development,
      but it also facilitates making changes to the assembler sources.
      A Makefile is provided to help automate updating the bytecode. It is not
      integrated with the automake system to avoid forcing an ARM cross-compiler
      onto every user, i.e. after modifying the sources they need to be rebuilt
      in that directory before building the usual way. ARM_CROSS_COMPILE= can
      be passed on the make command line to deal with native ARM toolchains
      or with varying prefixes of cross-toolchains.
      Change-Id: I00ceb980a68c8554a180dd13719ac77b677a8bcd
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-on: http://openocd.zylin.com/3133
      Tested-by: jenkins
      Reviewed-by: default avatarAndreas Fritiofson <andreas.fritiofson@gmail.com>
      Reviewed-by: default avatarPaul Fertser <fercerpav@gmail.com>
    • Andreas Färber's avatar
      flash: New Spansion FM4 flash driver · 43ff5acd
      Andreas Färber authored
      The Spansion FM4 family of microcontrollers does not offer a way to
      identify the chip model nor the flash size, except for Dual Flash vs.
      regular layout. Therefore the family is passed as argument and
      wildcard-matched - MB9BFx6x and S6E2CC families are supported.
      Iterations showed that ...
      1) Just doing the flash command sequence from SRAM loader code for each
      half-word took 20 minutes for an 8 KB block.
      2) Doing the busy-wait in the loader merely reduced the time to 19 minutes.
      3) Significant performance gains were achieved by looping in loader code
      rather than in OpenOCD and by maximizing the batch size across sectors,
      getting us down to ~2 seconds for 8 KB and ~2.5 minutes for 1.1 MB.
      (Tested with SK-FM4-176L-S6E2CC-ETH v11, CMSIS-DAP v23.)
      gcc, objcopy -Obinary and bin2char.sh are used for automating the
      integration of hand-written assembler snippets.
      Change-Id: I092c81074662534f50b71b91d54eb8e0098fec76
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-on: http://openocd.zylin.com/2190
      Tested-by: jenkins
      Reviewed-by: default avatarSpencer Oliver <spen@spen-soft.co.uk>
  27. 26 Nov, 2015 1 commit
  28. 11 Nov, 2015 1 commit
    • Jeff Ciesielski's avatar
      flash: New driver for XMC4xxx microcontroller family · 33b048d4
      Jeff Ciesielski authored
      This is a complete flash driver for the Infineon XMC4xxx family of
      microcontrollers, based on the TMS570 driver by Andrey Yurovsky.
      The driver attempts to discover the particular variant of MCU via a
      combination of the SCU register (to determine if this is indeed an
      XMC4xxx part) and the FLASH0_ID register (to determine the variant).
      If this fails, the driver will not load.
      The driver has been added to the README and documentation.
      * Hardware: XMC4500 (XMC4500_relax), XMC4200 (XMC4200 enterprise)
      * SWD + JTAG
      * Binary: 144k, 1M
      * Flash protect only partly tested. These parts only allow the flash
        protection registers (UCB) to be written 4 times total, and my devkits
        have run out of uses (more on the way)
      Future Work:
      * User 1/2(permalock) locking support via custom command
      * In-memory flash loader bootstrap (flashing is rather slow...)
      Change-Id: I1d3345d5255d8de8dc4175cf987eb4a037a8cf7f
      Signed-off-by: default avatarJeff Ciesielski <jeffciesielski@gmail.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Reviewed-on: http://openocd.zylin.com/2488
      Tested-by: jenkins
      Reviewed-by: default avatarPaul Fertser <fercerpav@gmail.com>
  29. 30 Oct, 2015 1 commit