Otherwise it breaks SWD targets. The check seems really weird anyway since
it loops through *all* TAPs after the ADIv5 target but doesn't do anything
at all with the result, other than not setting the return values despite
returning ERROR_OK.
Remove a bogus initialization that was needed because of the odd
behaviour of this routine when an IDCODE wasn't found.
Change-Id: Ic086352f6af868b3406b00420291a0a671e3acac
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1953
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Fix bug in parity calculation macro.
Cache and update the selected DP bank when necessary.
Add aborts when the Ack code signals a failure (we should really only
clear the sticky bits, but this will do for now).
Change-Id: I38a4da136ba1d9e989b33c1875a80c0b1b2be874
Signed-off-by: Fatih Aşıcı <fatih.asici@gmail.com>
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/1950
Tested-by: jenkins
The -n option is non-standard and is unavailable on some systems
(e.g. OS X's shell builtin).
Change-Id: Ia2fed186dee5fa6da543944873d67ebee1d9354e
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2172
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
The JLink protocol description doesn't really specify it for
JTAG-level commands but the real life evidence is that 0x01 error code
means "Adaptive clocking timeout" as it does for e.g. WRITE_MEM_ARM79.
Change-Id: I4e3b568742814271919f92d202713968c8fcccfb
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2169
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Add part IDs for the new SAMD10 and SAMD11 parts within the Atmel SAMD
family, they have the same Flash controller as the other samd parts and
should be supported by the at91samd driver. Compile-tested only.
Change-Id: I493ae96a7d7e8d19e607fd9a4b6544a982be42b3
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2170
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
fm3 flash driver needs to know which chip variant is used.
This fixes "unknown fm3 variant: mb9bf500.cpu" error if the config is
used as is.
Change-Id: I500fcfb413f23ee246678cec5bd19d14139a28e2
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2160
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
while investigating coresight components, i've found some new partnumbers and devtypes.
Change-Id: Ie68032b0b21d542c2084f80db38b06f5cd4c7591
Signed-off-by: Jiri Kastner <cz172638@gmail.com>
Reviewed-on: http://openocd.zylin.com/2166
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The error message (with the usage field unpopulated) looks like this,
obviously missing at least a space before Usage:
Error: 'fm3' driver rejected flash bank at 0x00000000Usage (null)
Change-Id: I2a625676e784d02942823f972a201f7f4f810c68
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2161
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This results in a 90% speedup on USB-Blaster, which serializes repeated
TDI input against TDO readback; program time on an 5CGXFC5C6F27 part was
dropped from 2m30s to 9s.
Signed-off-by: Joshua Wise <joshua@joshuawise.com>
Change-Id: I92d5a8b800492283d619328549235b610528c338
Reviewed-on: http://openocd.zylin.com/2145
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This isn't needed nor a recommended practice now, was a simple
copy/paste from amdm37x.cfg anyhow.
Change-Id: I064226dc859d7563cfad945b577279fc37448645
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-on: http://openocd.zylin.com/2068
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
On a processor with caches, when you write data to memory OpenOCD invalidates
the cache lines affected. If you write to an address within 64 bytes of
UINT32_MAX, then the for loop control variable wrapped around resulting in an
infinite loop. Change control variable to be an offset from the address
involved. We should never be asked to write 2^32 bytes, so wraparound should
not be a problem.
Change-Id: Ibfe654113eff71684862ff651e7a1cd05ccc6760
Signed-off-by: Seth LaForge <sethml@google.com>
Reviewed-on: http://openocd.zylin.com/2126
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
HLAs do not provide direct DAP access, so the best we can do about it
is skipping it.
Change-Id: I877ef8fd2d86e40e7442a637cdba182cfd60e05a
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2173
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
We don't need to swap the endianness in the target generic code.
This swap is necessary because of the adv_debug_if debug unit.
This patch moves this specific piece of code from or1k.c to
or1k_du_adv.c.
Change-Id: I3acea092fe6edfa79b4a87861b5f01204f071bf0
Signed-off-by: Franck Jullien <franck.jullien@gmail.com>
Reviewed-on: http://openocd.zylin.com/1663
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Maximum frequency wasn't tested on hardware but the docs seem to be
quite explicit and do not mention any restrictions for that.
Change-Id: Idcf58df5358d06525e683f07c76eedad8f0b292d
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2120
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Adds support for auto-probing on devices which support the IAP
Read Part ID command. Includes IDs for all LPC17XX, LPC13XX,
LPC11XX and LPC11XXX devices with publicly available user
manuals.
To use auto-probing, select the 'auto' lpc2000 variant.
Change-Id: Ic617c32925c9ebe0e9d9192ed8ddbfa08e9f0aaa
Signed-off-by: Cosmin Gorgovan <cosmin@linux-geek.org>
Reviewed-on: http://openocd.zylin.com/2075
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
