This combination is known to work properly with 2MHz JTAG clock.
Change-Id: Ie5ec3d3b415efbb13faee7d34e0c7f862b78350c
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2266
Tested-by: jenkins
Since now auto-detection for flash size works nicely, there's no
reason to keep numerous configs around.
Change-Id: If0cbc37985abf17ef7c1f7d0688e76500fac228f
Signed-off-by: Vanya Sergeev <vsergeev@gmail.com>
Reviewed-on: http://openocd.zylin.com/1960
Tested-by: jenkins
Reviewed-by: Freddie Chopin <freddie.chopin@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This adds config to allow JTAG debugging of an ARM core of a modern
hybrid SoC by Research Centre "Module"
(http://www.module.ru/en/company/). К1879ХБ1Я is targetted at set-top
boxes and other multimedia equipment, the official SDK is Linux-based.
Change-Id: Ib2ae5784d25699f952682e66b025a3f677a76d5d
Signed-off-by: Бурага Александр <dtp-avb@yandex.ru>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2272
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
According to the research by Eldar, TINY-H adapter has nTRST connected
to ACBUS0 directly via a 100 Ohms series resistor. I think it's safe
to assume the older TINY adapter does the same.
See high-res photos at [1].
This patch should fix issues with JTAG for the case when nTRST is
actually connected but is missing from the config.
[1] https://wikidevi.com/wiki/Olimex_ARM-USB-TINY-H
Change-Id: Iaaee7be30536ebb502802d38b82cd9573408f854
Reported-by: Хайруллин Эльдар <eldar.khayrullin@mail.ru>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2247
Tested-by: jenkins
Reviewed-by: demokmail <demokmail@gmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Luckily, TI's website has predictable URLs for the datasheets, so it
was trivial to download all the pdfs corresponding to the currently
available 71 TivaC devices. Then they were processed with pdftotext
and parsed by this script:
BEGIN { capture = -1 }
/^Device Identification 0 \(DID0\)$/ { state = "waitingclass0" }
/^Device Identification 1 \(DID1\)$/ { state = "waitingpartno0" }
/^CLASS$/ { if (state == "waitingclass0") state = "waitingclass"
else if (state == "waitingclass") capture = 4 }
/^PARTNO$/ { if (state == "waitingpartno0") state = "waitingpartno"
else if (state == "waitingpartno") capture = 4 }
(FNR == 3) { family = $2 }
{
if (capture >= 0) {
if (capture == 0) {
if (state == "waitingclass")
class = $0
else if (state == "waitingpartno")
partno = $0
}
capture--
}
}
END { print "{" class ", " partno ", \"" family "\"}," }
Change-Id: I6820c409fe535f08394c203276b5af4406fe8b92
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2262
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This should make current Tiva C parts usable apart from the protection.
Runtime tested on TM4C123GXL (Blizzard) and TM4C1294XL (Snowflake).
Change-Id: Ia64e9d39fbd2b7049578bbfade72435e5203ddf5
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2257
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This struct and libusb_get_device_descriptor() method are not present
in libusb-0.1 API, so when libusb-1.0 is unavailable, this code breaks
the build. Fix by using the appropriate struct (which is apparently
filled automatically on device initialisation).
While at it, change return values for consistency with the callers.
Change-Id: I7d85ab9a70401a155a65122397008ae4d81382fe
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2252
Tested-by: jenkins
Reviewed-by: Austin Phillips <austin_phillips@hotmail.com>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
When SWD mode is not supported by the target adapter, the call should
return an error instead of segfaulting.
Change-Id: I1626097deb93ecfbe78a6e82d812c7a673dbbde5
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2256
Tested-by: jenkins
Commit f701c0cb seems to have introduced a regression for non-JTAG
transports as the newly created "tap" (DAP actually) ended up being
disabled, thus resulting in total lack of functionality.
This was exposed by a debug log demonstrating ftdi SWD transport
connection to mdr32f9q2i, the target wasn't examined on init and
couldn't be reset.
Change-Id: If53cbe800d4adc177aa3ac3219860e7fa15b3e49
Reported-by: Хайруллин Эльдар <eldar.khayrullin@mail.ru>
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2261
Tested-by: jenkins
Reviewed-by: Angus Gratton <gus@projectgus.com>
Reviewed-by: Nemui Trinomius <nemuisan_kawausogasuki@live.jp>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This adds initial support for the STM32L0 family, specifically the ID
code 417 variant. The 'L0 has 128B rather than 256B pages as well as a
different number of pages per sector. It also has several key registers
and register sets in different locations from the STM32L1xx parts.
This change therefore takes the opportunity to reorganize part information into
a const table (it was previously determined by a set of control statements) and
abstracts away some of the low-level details to make them generic for L1 and
L0 parts.
We also include the first bank's size (for dual bank parts) in the new
device information table (and correct that size for the 0x437 variant
which is 256 rather than 192KB).
The 'L0 parts will not use the built-in loader/helper for Flash writing.
Tested on STM32L053 (dicovery board and Nucleo board) and STM32L152
(discovery board).
Change-Id: I57f7a8ab02caee266de71b31ae82a50d85728a0b
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2200
Tested-by: jenkins
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
This was somehow missed in the chip ID table and of course that's
exactly the one on my board (as such, tested on hardware).
Change-Id: I212d7c729d979e0357f1d4635f40935e25fe6ff3
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-on: http://openocd.zylin.com/2260
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Fitted to various Analog Devices ADuCM36x dev boards.
Change-Id: Ib3691704c0ecd2f8cba1abba284aee695d6bc135
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/2244
Tested-by: jenkins
As Daniel pointed out, since the rewrite of the USB Blaster driver, the
initialization behaviour has change. The initial flush of the FIFOs is
not longer done with a specific USB setup packet, but with a write
filling up the blaster queues.
The problem is, quoting Daniel :
When the CPLD is in bit banging mode (as is usually the case), the
first 0x00 byte sets all pins to low and disables the output
driver. Disabling the output drivers is a few nanoseconds slower
than changing a pin from high to low, so I see a spike towards GND
on my reset line when that byte is sent over USB. The spike is too
short to have an effect on the board.
When the 4096 0x00 bytes are processed and the TMS=1 is to be
generated, all I see is several microseconds of low level on all
pins, resetting my board.
This patch changes the way the initialization is done :
- at driver init, nothing is sent towards the usb-blaster
This gives time for init script to setup PIN6 and PIN8 (resets)
- at the very first driver command, the initialization is done :
- the output is in bit bigbang mode
- the PIN6 and PIN8 are computed according to init script
- the 4096 computed output is sent
Change-Id: If7ceee957f6b59bcb27c8f912f1cfdd0f94f75ed
Reported-by: Daniel Glöckner <daniel-gl@gmx.net>
Cc: Franck Jullien <franck.jullien@gmail.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reviewed-on: http://openocd.zylin.com/2229
Tested-by: jenkins
Reviewed-by: Franck Jullien <franck.jullien@gmail.com>
Reviewed-by: Daniel Glöckner <daniel-gl@gmx.net>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Even though changing transport is impossible, reselecting it should be
harmless.
Change-Id: I6c1c2786134e826f47f848b590e6d712b6fd2206
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2251
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
