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: Andreas Färber <afaerber@suse.de>
Reviewed-on: http://openocd.zylin.com/2190
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This adds docs, example config, flash driver.
Driver is only supports K1921VK01T model for now.
Change-Id: I135259bb055dd2df1a17de99f066e2b24eae1b0f
Signed-off-by: Bogdan Kolbov <kolbov@niiet.ru>
Reviewed-on: http://openocd.zylin.com/3011
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@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>
This is a new driver for Silicon Laboratories SiM3 microcontroller
family, based on the work of Ladislav Bábel. The driver will try to
detect the type of MCU from the device id register, and if this
fails it will use the flash size from the flash bank command.
Driver added to the documentation and to the README.
TCL script added.
Tests:
* Hardware: SiM3C166 (pre-production) and SiM3U167
* Binary: 4kb, 197kb, 256kb
* Flash protect not tested
Change-Id: I701e0cf505ca8ad99be7f83543fe5055b2f65dcc
Signed-off-by: Andreas Bomholtz <andreas@seluxit.com>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2078
Tested-by: jenkins
New NOR flash driver was derived from stm32lx.
Procedure ocd_process_reset_inner is overriden in psoc4.cfg
to handle reset halt and system ROM peculiarities.
Change-Id: Ib835324412d106ad749e1351a8e18e6be34ca500
Signed-off-by: Tomas Vanek <vanekt@fbl.cz>
Reviewed-on: http://openocd.zylin.com/2282
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Tested on ZedBoard by Tim Sander.
Change-Id: I4316d9b4d36f01bbe91a46c78ea8bca22efb1a5a
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2029
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Also add missing entries for JTAG-lock-pick Tiny 2, Xverve Signalyzer
LITE and default FTDI VID:PIDs.
Change-Id: I41b4f15409642298d1cf134d1f8014dc8f003005
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1969
Tested-by: jenkins
Intel Quark X10xx SoC debug support added
Lakemont version 1 (LMT1) is the x86 core in Quark X10xx SoC
Generic x86 32-bit code is in x86_32_common.c/h
Change-Id: If2bf77275cd0277a82558cd9895b4c66155cf368
Signed-off-by: adrian.burns@intel.com
Reviewed-on: http://openocd.zylin.com/1829
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
m4_argn macro was introduced in v2.63b-34-g46e87de on the 22nd of Apr 2009.
Change-Id: Id01cc9f0ffdb46cf6dfd26c3bf3b5efa0ddd2984
Reported-by: Franck Jullien <franck.jullien@gmail.com>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1656
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This updates README with all the "keywords" added since the initial
upstream submission (and finally fixes the typo in the beginning).
Change-Id: Ia071267246fe6afc19fc0bfcda83c4778e7ff5b1
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1624
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
An alternative approach to show how much cleaner the pure pkg-config
way is.
This changes the discovery procedures for libusb-1.0 and libusb-0.1,
making them depend on pkg-config being properly installed and
configured, including the necessary build host configuration for the
cross-builds (see
http://www.flameeyes.eu/autotools-mythbuster/pkgconfig/cross-compiling.html)
It should make it possible to compile OpenOCD without changes and
extra effort on GNU/Linux, FreeBSD users would need to supply a .pc
file for their libusb implementation or add LIBUSB1_LIBS and
LIBUSB1_CFLAGS to the configure environment.
Change-Id: I826e378dd1e0d101a549a573b2c63212a7e00b64
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1467
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Tested-by: Spencer Oliver <spen@spen-soft.co.uk>
This is an attempt to bring the README files in line with the current
status of the OpenOCD development.
- remove some obsolete information and duplicated instructions
- reword some statements
- restructure in a way more appealing to a regular user
- add a supported hardware list to allow a potential user to determine
if his/her usecase is covered by a freetext keyword search through
the document
- Add OSX notes (courtesy GrizzlyAdams and inca)
Since most ftdi-based adapters are now covered by the ftdi driver, I
think it's ok to remove some of the libftdi/ftd2xx instructions, the
few users who still need them should refer to upstream docs instead.
I'm not sure if README.Windows should come with the DOS line endings,
but i'd expect many windows users to use their silly notepad to view
it, and notepad ignores LF apparently. (Decided to use LF anyway.)
I understand discussing and reviewing such a massive README change is
a somewhat demanding task but I feel it's a necessity to move forward
maintaining proper documentation.
Change-Id: Idfde3014c72dd5c32ad292ee1ab205322e51a138
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1503
Tested-by: jenkins
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
There're strong arguments against using this macro (mostly regarding
build consistency), so remove it altogether.
Change-Id: I90c8e9a86a24571019366435bd868a6799a09c45
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1476
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This makes libusb handling more consistent: if any driver requires
libusb, first check for libusb-1 availability, if not found and
libusb0 is ok for this case, try libusb0.
A user-visible bug fixed by this is that when a user was selecting a
driver that required libusb-1 but was lacking the necessary dev files
or libraries, configure didn't complain (but the build was failing of
course).
--enable-stlink doesn't really require libusb-1 but since it's using the
same automake symbol HLAADAPTER, ti_icdi is getting built too which needs
libusb1 unconditionally. Since using libusb-0.1 makes little sense anyway,
leave that as is.
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Change-Id: I630a4ad9e4583743d45b2233bf5d8f4e5c0aab82
Reviewed-on: http://openocd.zylin.com/1434
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Without the explicit dir at the end the repository will be cloned to "code".
Change-Id: Icd8b55b4ba74f23b214c3844e2fb785377768119
Signed-off-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-on: http://openocd.zylin.com/1349
Reviewed-by: Øyvind Harboe <oyvindharboe@gmail.com>
Tested-by: jenkins
These were missed when git was moved to the new SF platform during Nov 2012.
Change-Id: I7b4ae9dea010d95f9bf4c26841b5b724f41768be
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1248
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Tested-by: jenkins
This is the new proprietary interface replacing the older FTDI based adapters.
It is currently fitted to the ek-lm4f232 and Stellaris LaunchPad.
Change-Id: I794ad79e31ff61ec8e9f49530aca9308025c0b60
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/922
Tested-by: jenkins
this never panned out and there are enough mistakes in
the code that probably nobody used this.
Use the tcl server and implement a standalone http
app instead works fine.
Signed-off-by: Øyvind Harboe <oyvind.harboe@zylin.com>
The FT2232H really wants libftdi 0.17 or newer; some notable
bugs got fixed in that version.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Specifically the Linux issue of needing "udev" rules, and MS-Windows
needing driver configuration.
Also, update the existing udev note to use the correct name of that
rules file in the source tree.
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Add --disable-doxygen-html and --enable-doxygen-pdf options to the
configure script, allowing user to change the defaults. These
update the proess of munging the Doxygen configuration file to
use the settings thusly provided. Add options in README.
Also, talk about "mainline" not "trunk".
The release.txt and release.sh files need more updates.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2825 b42882b7-edfa-0310-969c-e2dbd0fdcd60
- warning now issued if high speed ftdi device found and openocd was built using an old driver
git-svn-id: svn://svn.berlios.de/openocd/trunk@2599 b42882b7-edfa-0310-969c-e2dbd0fdcd60
https://lists.berlios.de/pipermail/openocd-development/2009-August/009939.html
1. It can only be built with the FTD2XX driver. libftdi supports FT2232H/FT4232H
since version 0.16
2. A speed value of 0 is used as a RTCK request indicator. This clashes with the
valid clock division value 0 that provide the highest fixed clock frequency.
3. The ft2232_speed_div function return the maximum selectable frequency (30MHz)
when RTCK is activated. It should return 0.
4. The ft2232_khz function return ERROR_OK when RTCK is requested even for
devices lacking RTCK support. It should return ERROR_FAIL so the upper driver layers
can detect this and try to fallback to a fixed frequency.
5. FT2232H/FT4232H have a backward compatibility function that divide the clock
by 5 to get the same frequency range as FT2232D. There is no code that disable
this functionality. I can not find anything about if this is enabled or disabled by default.
I think it is safest to actively disable it.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2591 b42882b7-edfa-0310-969c-e2dbd0fdcd60
More minor improvements to README to help polish the 0.2.0 release:
- Add note about Ubuntu 8.04 (in lieu of starting a README.Linux file).
- Fix introductory paragraph to Bulding OpenOCD
- Remove some vestigial texinfo markup.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2448 b42882b7-edfa-0310-969c-e2dbd0fdcd60
Add some text to introduce the project to new users.
Move packaging, configuration, and compilation of OpenOCD out of
the User's Guide and into README, where it can be used by users
before configuring and compiling the documentation.
Improve notes about required Subversion repository build steps.
Add reference to the standard GNU INSTALL file.
git-svn-id: svn://svn.berlios.de/openocd/trunk@2436 b42882b7-edfa-0310-969c-e2dbd0fdcd60