output for flash page writes
The offset wasn't being considered in the "full page" write codepath, so any
writes at an offset were actually written out starting from page 0.
Change-Id: I5e70a1f35f144b3edd1ce6d9df9af9b5da6cf194
Signed-off-by: Angus Gratton <gus@projectgus.com>
Reviewed-on: http://openocd.zylin.com/1965
Tested-by: jenkins
Reviewed-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
The JLink-OB (onboard) devices work the same way as the normal JLink
except that their PID is 0x0105 (and that's the only one we know of so
far) and their endpoint addresses are different due to there being a
CDC-ACM interface as well. These JLink-OB devices show up on a lot of
vendors' development kits as an integrated debugger.
This change simply checks whether the adapter we opened has a JLink-OB
PID and, if it does, uses the JLink-OB endpoints rather than the
default. To do this, we add a new routine, jtag_libusb_get_pid() to the
libusb adapter layer, it in turn just calls
libusb_get_device_descriptor(), which previously had no wrapper.
Also, checkpatch.pl doesn't like the VID/PID macros as defined so I
moved them to the array itself. This should have no effect on the code.
This change adds the 0102 through 0104 PIDs to openocd.rules as well as this
new 0105 PID.
Tested on an Atmel SAM4S Xplained board which has a JLink-OB, also
regression tested by using a 0x0101 PID normal JLink adapter.
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
Change-Id: I121d30e57729cda3adb66e2a5dc72e1fcb7ef8b1
Reviewed-on: http://openocd.zylin.com/2031
Tested-by: jenkins
Reviewed-by: Xiaofan <xiaofanc@gmail.com>
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
This adds support for the am43xx SoC and the AM437x GP EVM and AM438x
ePOS EVM.
Change-Id: I09cbb09072f38e0e08fdd520dedb6e67d45056be
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-on: http://openocd.zylin.com/2047
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
instead of replicating icepick_d_tapenable in many of TI's newer
platforms, we can move to icepick.cfg and just call it from board TCL
configuration file. This is similar to the C but has a few changes we
need to make.
Change-Id: I0ab48005ccd66cd5b67b919fb5e3b462288f211d
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tom Rini <trini@ti.com>
Reviewed-on: http://openocd.zylin.com/2030
Tested-by: jenkins
Reviewed-by: Paul Fertser <fercerpav@gmail.com>
From testing this target does not seem to support using SYSRESETREQ, change
the default to the safe VECTRESET.
This target also has other reset issues (srst not working) that will be
addressed in another patch.
Change-Id: Icfc78347dc71aa3a062ddea63190a818d7fbc760
Signed-off-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-on: http://openocd.zylin.com/1995
Tested-by: jenkins
Reviewed-by: Angus Gratton <gus@projectgus.com>
As suggested by Stian Skjelstad in a comment in:
http://openocd.zylin.com/#/c/2044/
if the USB product string cannot be read, provide a debug message so
users might get aware of a potential permission problem when looking
at the debug output.
Fix style bug found by Jenkins.
Change-Id: I6acb1c6261fec6f2bee80e4be513a5c5e29eff79
Signed-off-by: Jörg Wunsch <openocd@uriah.heep.sax.de>
Reviewed-on: http://openocd.zylin.com/2048
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Atmel's SAM3 and SAM4 processor families are very close to each other
in many respects. However, so far, only the SAM4 target script
contained the magic to allow using SWD, while SAM3 was tied to JTAG
only. This e.g. prevented the CMSIS-DAP driver from accessing SAM3
devices as it only uses SWD transport (by now).
The patch pulls all the things from the SAM4 target script that are
also applicable to SAM3 devices. With the patch, an Atmel CMSIS-DAP
debugger (Atmel-ICE) was proven to be able to successfully attach to a
SAM3S-EK evaluation kit. I also cross-checked that accessing through
a SAM-ICE (Segger J-Link) still works with the patch.
Change-Id: I20dafbff8e1e9f967da950e48a56205586eeef8d
Signed-off-by: Jörg Wunsch <openocd@uriah.heep.sax.de>
Reviewed-on: http://openocd.zylin.com/2046
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The existing CMSIS-DAP driver matches the USB VID/PID against 0x3eb
(Atmel VID) and 0x2111 (Atmel EDBG embedded CMSIS-DAP debugger), and
then bumps the packet size from its default of 64 to 512. However, it
turned out that *all* Atmel-provided CMSIS-DAP devices (EDBG with PID
0x2111; JTAGICE3 with firmware version 3.x, PID 0x2140; new Atmel-ICE
[successor of JTAGICE3], PID 0x2141) require a 512-byte packet size.
Obviously, all run the same USB implementation inside their custom
microcontroller. Thus, it seems best to simply assume that *all*
Atmel CMSIS-DAP devices use this packet size, and don't check the PID
at all.
This has also been filed as Trac bug #68:
https://sourceforge.net/apps/trac/openocd/ticket/68
Change-Id: I942af93060fdf265fca3961841638caa6182f877
Signed-off-by: Jörg Wunsch <openocd@uriah.heep.sax.de>
Reviewed-on: http://openocd.zylin.com/2045
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Reviewed-by: Andrey Yurovsky <yurovsky@gmail.com>
In the CMSIS-DAP driver, if nothing has been specified by the user, an
attempt is made to find the first device with the (mandatory)
substring "CMSIS-DAP" in any USB device's product string. However,
while (usually) all devices can be traversed, devices the user does
not have permission for cannot be read the product string from,
resulting in a NULL pointer. Trying to find the substring "CMSIS-DAP"
causes a segementation fault then.
This has also been filed as Trac bug #67:
https://sourceforge.net/apps/trac/openocd/ticket/67
Change-Id: Idfc9f072e34152e9af99fe1c8ec88c99dea4624c
Signed-off-by: Jörg Wunsch <openocd@uriah.heep.sax.de>
Reviewed-on: http://openocd.zylin.com/2044
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
Nucleo F401 board uses STM32F401RE chip with new device id and
got more flash than existing devices (512K). This patch adds
new the identifier to probe functions so flashing will now work.
Change-Id: Ibe9c047c79244db0cfbb06610da9d84987b9f85a
Signed-off-by: Jens Hoffmann <jehoffma@gmail.com>
Reviewed-on: http://openocd.zylin.com/2037
Tested-by: jenkins
Reviewed-by: Andrey Yurovsky <yurovsky@gmail.com>
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
The timer callback is started on target init, but it makes no sense to
poll until the target is fully setup.
Change-Id: I118201e125e39be3d0a920e3ef9a3f68a2035f39
Signed-off-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
Reviewed-on: http://openocd.zylin.com/2041
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
This should provide enough information to start using OpenOCD RPC.
I've seen some other example clients in different languages but I
can't find them anymore, and their legal status was unclear.
Change-Id: I3a95fe361d773040d1e52a62f9cc0cc655019a9f
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/1915
Tested-by: jenkins
Reviewed-by: Andreas Ortmann <ortmann@finf.uni-hannover.de>
Reviewed-by: Andreas Fritiofson <andreas.fritiofson@gmail.com>
We always have feature names defined by string literals and the
standard guarantees static storage duration for them. Hence, there's
no need duplicating and then freeing them.
Valgrind-tested.
Change-Id: I1b77f966c548e3694141c63bd8680735f0f47505
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Reviewed-on: http://openocd.zylin.com/2028
Tested-by: jenkins
Reviewed-by: Spencer Oliver <spen@spen-soft.co.uk>
