Hello Drasko,
The end goal it's to have a safe state of the used JTAG adapter at the
end of the executable file.
With this patch => Fix: Correctly exit function: ft2232_init when an
error occurred
I wish correct the status at the end of ft2232_init function when an
error occured.
At this mom
The problem is that the ft2232_init() fn will invoke
jtag_xxx() fn's.
However, until ft2232_init() returns, the interface is
not set up and that part of the API is not "open for business",
causing strange effects.
ft2232_init() sets up a "default speed". We have been talking
about making JTAG spe
I've noticed strange behaviour in initialization with TI OMAP4430 and
Freescale iMX53 using Amontec JTAGKEY. Even typing keys on OpenOCD shell
was very very slow.
I didn't investigate too much the causes. Anyway this patch fix it.
Signed-off-by: Luca Ellero
---
src/jtag/core.c |2 +-
1 files
On 04/26/2011 12:17 PM, Paolo Pisati wrote:
> Any idea?
>
bad wiring on my side:
Open On-Chip Debugger 0.5.0-dev-00858-g3c6af51 (2011-04-26-12:13)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect '
On Tue, Apr 26, 2011 at 3:19 PM, Xiaofan Chen wrote:
> On Tue, Apr 26, 2011 at 9:05 PM, Øyvind Harboe
> wrote:
>>> Like this one?
>>> http://www.segger.com/cms/jlink-flash-breakpoints.html
>>
>> Yep. :-)
>>
>> They say performance isn't a problem.
>>
>> Anyone want to put together a patch?
>
> S
On Tue, Apr 26, 2011 at 9:05 PM, Øyvind Harboe wrote:
>> Like this one?
>> http://www.segger.com/cms/jlink-flash-breakpoints.html
>
> Yep. :-)
>
> They say performance isn't a problem.
>
> Anyone want to put together a patch?
Some say it is patented but I do not know what is really patented.
http
> Like this one?
> http://www.segger.com/cms/jlink-flash-breakpoints.html
Yep. :-)
They say performance isn't a problem.
Anyone want to put together a patch?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.
On Tue, Apr 26, 2011 at 4:20 PM, Øyvind Harboe wrote:
> Here is an idea for a new feature: sw breakpoints in flash.
>
> The way this feature would work would be to detect if
> a breakpoint is in the flash region. If it is, a hw breakpoint
> would be used until the hw breakpoints run out.
>
> At th
> Right. However, I do think these are the only way to go if you want SW
> breakpoints in flash, so having support for flash patch units would be quite
> handy.
> Otherwise, HW breakpoints are the only alternative that really works.
Are these flash patching units part of vendor IP or is it somethi
On 04/26/2011 10:20 AM, Øyvind Harboe wrote:
Here is an idea for a new feature: sw breakpoints in flash.
The way this feature would work would be to detect if
a breakpoint is in the flash region. If it is, a hw breakpoint
would be used until the hw breakpoints run out.
At that point the flash s
[flag@newluxor openocd]$ dpkg -l | grep ftd
ii libftdi-dev
0.18-1Development files for
libftdi
ii libftdi1
0.18-1Library to control and
program the FTDI USB
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-dev
Merged.
THanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-de
Here is an idea for a new feature: sw breakpoints in flash.
The way this feature would work would be to detect if
a breakpoint is in the flash region. If it is, a hw breakpoint
would be used until the hw breakpoints run out.
At that point the flash sector would be rewritten with the
sw breakpoint
14 matches
Mail list logo
