attaching
a somewhat ugly patch that resolves the issue.
Regards,
Dimitar Dimitrov
Index: src/helper/options.c
===
--- src/helper/options.c (revision 1355)
+++ src/helper/options.c (working copy)
@@ -80,6 +80,28 @@
strcat
Hi,
I'm trying to debug SAM9-L9260 board /AT91SAM9260 chip/ using the latest GIT
openocd checkout, FTDI-based dongle and libftdi-0.16. I made the following
minor fix to the board cfg:
-
diff --git
I applied the patches but I got the following error:
Error: 228 7449 ft2232.c:419 ft2232_read(): couldn't read the requested number
of bytes from FT2232 device (0 6)
After increasing the FT2232 timeouts (patch attached) the reset init command
completed successfully.
Then I tried to load an
Hi,
I'm trying to debug SAM9-L9260 board /AT91SAM9260 chip/ using the latest GIT
openocd checkout, FT2232H-based dongle and libftdi-0.16. I'm getting the
following error when issuing reset init:
Error: 228 7449 ft2232.c:419 ft2232_read(): couldn't read the requested number
of bytes from
and with external USB hub. Meanwhile,
however, I'm open for suggestions.
Regards,
Dimitar
On Tuesday 27 October 2009, David Brownell wrote:
On Tuesday 27 October 2009, Dimitar Dimitrov wrote:
I'm trying to debug SAM9-L9260 board /AT91SAM9260 chip/ using
the latest GIT openocd checkout, FT2232H
I fixed the issue by disabling dcc memory uploads. Otherwise my setup hasn't
changed:
1. Openocd fetched from latest GIT
2. libftdi-0.16 from the latest release tarball
3. FT2232 timeout/retry-count patch applied (attached).
4. ARM-USB-TINY-H interface config (attached)
After starting openocd I
On Sunday 25 October 2009, you wrote:
If you could report back on whether software breakpoints
work in memory marked as read only by the MMU that
would be fantastic.
Where can I find an example application that enables the MMU and marks code
regions as read only?
Dimitar
On Friday 30 October 2009, David Brownell wrote:
On Thursday 29 October 2009, Dimitar Dimitrov wrote:
I fixed the issue by disabling dcc memory uploads.
Bizarre. Disabling those let the initial enumeration
work at full speed?? Or was that caused by some other
patches in your repository
On Tuesday 02 February 2010 04:29:36 David Brownell wrote:
On Monday 01 February 2010, Xiaofan Chen wrote:
I do not think libusb0.dll is the problem. It is said that arm-jtag-ew
emulates the J-Link in low level API. It takes quite some for
OpenOCD to get J-Link working properly. So I will
Could you run openocd with highest verbose messages level? Also turn on the
usb comm and I/O debug options from the configure script invocation?
Regards,
Dimitar
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
On Wednesday 03 February 2010 14:55:20 Nick wrote:
here is my output:
Info : ARM-JTAG-EW firmware version 1.4, hardware revision A,
SN=OL24B4C000F43EE, Additional info: Date of firmware comp ilation: Sep 10
2009, 15:55:50, Source revision: 823
Info : U_tg = 3235 mV, U_aux = 0 mV, U_tgpwr =
Try latest git. You will need to remove the old autosetup/jimsh0.exe
It's a good idea to run 'git clean -f -d -x' prior to running
autotools and friends. This will erase all files and directories that
aren't under revision control.
Regards,
Dimitar
___
. This was probably the reason for the additional errors (JTAG
chain timeout (?), as in private email from Dimitar Dimitrov, the
original author of the driver and a former Olimex employee).
Good catch! JTAG chain timeout is expected in such circumstances.
Clocking the (presumably full) 4k buffer
13 matches
Mail list logo
