Tested on PSoC6 (Cortex-M0+ core), onboard KitProg2 in CMSIS-DAP mode,
adapter_khz=1000.
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: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/4298
Tested-by: jenkins
Reviewed-by: Jonas Norling <jonas.norling@cyanconnode.com>
Reviewed-by: Andreas Bolsch <hyphen0break@gmail.com>
New STM8 target based mostly on mips4k. Target communication
through STLINK/SWIM. No flash driver yet but it is still possible
to program flash through load_image command. The usual target debug
methods are implemented.
Change-Id: I7216f231d3ac7c70cae20f1cd8463c2ed864a329
Signed-off-by: Ake Rehnman <ake.rehnman@gmail.com>
Reviewed-on: http://openocd.zylin.com/3953
Tested-by: jenkins
Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
arm-none-eabi target triplet defaults to Little Endian, and so far any
submitted machine code snippets have been verified to be Little Endian.
However a user might override [ARM_]CROSS_COMPILE with an armeb toolchain,
potentially resulting in invalid machine code.
Let's be safe and enforce Little Endian mode for assembler and compiler.
Change-Id: I9cefe24689eaded25d60ffb1f254b254e8d76f9d
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3498
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Add rules to build armv4_5_erase_check.inc, and convert the code to
target endianness the least intrusive way.
Drop an unused word from the assembler sources to make the ARM bytecode
fully match that of armv4_5.c and to not break ARMv4 assumptions.
This completes the build rules for contrib/loaders/erase_check directory.
Change-Id: I36be7a944e26142088195fa3fb072d4e577bf328
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3135
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
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: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3134
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
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: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/3133
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
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.
Tests:
* Hardware: XMC4500 (XMC4500_relax), XMC4200 (XMC4200 enterprise)
* SWD + JTAG
* Binary: 144k, 1M
Note:
* 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: Jeff Ciesielski <jeffciesielski@gmail.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/2488
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Tomas Vanek
Ake Rehnman
Andreas Färber
Jeff Ciesielski
Spencer Oliver