This works with a configured 72 MHz clock on the target,
in my case from the preprogrammed board test application.
The performance of the target flash controller is now the main
limiting factor.
I would commit this aswell, this could also be applied to the arm4_5 target.
Currently we
On Thu, 2 Apr 2009 18:22:33 +0800
SimonQian simonq...@simonqian.com wrote:
Hi,
Attached patch fixs:
1. call buf_cmp_mask to compare buffer with mask.
2. remove long lines according to GNU coding standard.
NOTE: The patch is untested, I don't have XC9572XL to test on.
And I'll prepare a
Hi,
The arm7_9 code has implemented run_algorithm_inner which is necessary
for target algorithms that communicates with the host using dcc.
This looks good and I think the other architectures should do the same,
but first I suggest some cleanups:
Add run_algorithm_inner and
Magnus Lundin wrote:
Hi,
The arm7_9 code has implemented run_algorithm_inner which is necessary
for target algorithms that communicates with the host using dcc.
This looks good and I think the other architectures should do the same,
but first I suggest some cleanups:
Add
Hi,
Sorry, it should be:
if ((svf_check_tdo_para[i].enabled)
(buf_cmp_mask(svf_tdi_buffer[index], svf_tdo_buffer[index],
svf_mask_buffer[index], len)))
If you cut [index], it will alway compare from the first data.
And in d3 mode, svf_check_tdo will be called
Spencer Oliver wrote:
This works with a configured 72 MHz clock on the target,
in my case from the preprogrammed board test application.
The performance of the target flash controller is now the main
limiting factor.
I would commit this aswell, this could also be applied to the
Spencer Oliver wrote:
This works with a configured 72 MHz clock on the target,
in my case from the preprogrammed board test application.
The performance of the target flash controller is now the main
limiting factor.
I would commit this aswell, this could also be applied to the
Hello!
While playing a bit with UrJTAG and miscelanous devices it turned out
that some devices requires nTRST, in particular ARM TDMI from NXP (LPC
family).
Because I was developing some application with OpenOCD and it was
working fine, I tried to evasdrop the OpenOCD signalling of JTAG.
By
Hi everyone,
I'm an experienced developer, but I'd have to say that I'm quite new
to JTAG. The concepts are fairly clear, but I don't have enough
experience debugging with JTAG to be able to make any predictions.
I've read the app note regarding isolation of the xscale nTRST nSRST
pins, and I
Patch in the attachment fix this problem.
If it is tested OK, I think this patch can be commited.
Hi,
ok, svf works fine, except gcc warning-
svf.c: In function ‘svf_check_tdo’:
svf.c:662: warning: unused variable ‘j’
:-)
JOhann
___
Hi,
Attachment is the patch.
Fix:
1. As Johann suggested, max line width is 80 characters, according to GNU
coding standard.
2. In svf_check_tdo, call buf_cmp_mask to do the comparation.
2009-04-03
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
Fix:
1. As Johann suggested, max line width is 80 characters,
according to GNU coding standard.
This is not a requirement of openocd
Theses are the openocd coding rules, they were part of the old readme but
need adding to the texi:
This is from the old readme - needs adding to the docs
So the patch in this mail is enough.
It fix only the svf_check_tdo function.
2009-04-03
Best Regards, Simon Qian
SimonQian(simonq...@simonqian.com) www.SimonQian.com
发件人: Spencer Oliver
发送时间: 2009-04-03 20:41:39
收件人: 'SimonQian'; 'openocd-development'
抄送:
主题: Re:
Hi,
I'm trying to build a config file for the IAR ST Butterfly Minі eval
board. This is what I have so far, but it doesn't work quite yet:
Index: src/target/board/iar_st_butterfly_mini.cfg
===
---
Is it possible the the processor core is held in reset ?
Basic JTAG is working.
It seems that communications with the debug port is also working,
the SWJ-DP OVERRUN messages comes at the right time :), we can add some
diagnostics to test this.
But trying to access memory mapped registers over
Uwe Hermann pisze:
I tried to set jtag_speed 0 in stm32.cfg, but that didn't help.
jtag_speed 0 gives you the maximum possible speed, as jtag_speed is a
divisor
from the manual:
DEPRICATED jtag speed - please use jtag khz above.
Limit the maximum speed of the JTAG interface. Usually, a
There is also a problem with error checking in the
swjdp_transaction_endcheck that creates a recusive loop with this type
of problem.
Try the following patch.
Index: src/target/cortex_swjdp.c
===
--- src/target/cortex_swjdp.c
On Fri, Apr 03, 2009 at 05:31:10PM +0200, Freddie Chopin wrote:
Uwe Hermann pisze:
I tried to set jtag_speed 0 in stm32.cfg, but that didn't help.
jtag_speed 0 gives you the maximum possible speed, as jtag_speed is a
divisor
Oops, true. I tried a few values for jtag_khz, e.g. 100, 10, and
Unless I'm mistaken, recent OpenOCD versions will automatically
work with both A and non-A variants of the ft2232_device_desc
variables. For example,
ft2232_device_desc Amontec JTAGkey
and
ft2232_device_desc Amontec JTAGkey A
should both work fine, on Windows as well as on Mac OS X and Linux,
Hi!
Some time ago, I had a problem with the rlink interface reporting too
many retries waiting for DTC status with the STM Primer, but didn't
submit a patch yet.
Here it is - it just increases the retry count to 10 (my cygwin setup
needs 7 retries in the worst case).
happy weekend,
--
As per OpenOCD flash programming STR9-comStick thread from a while
ago, here are two board files for the different revisions of the
Hitex STR9-comStick eval board.
Uwe.
--
http://www.hermann-uwe.de | http://www.holsham-traders.de
http://www.crazy-hacks.org |
7 files from the \src\target\target\ should actually be placed in
\src\target\board\ directory, as they are for evaluation kits or are not
a pure chip description. Attached patch removes them from the target
subdir, and places them in the board subdir, with some name changes to
describe the
Uwe Hermann pisze:
As per OpenOCD flash programming STR9-comStick thread from a while
ago, here are two board files for the different revisions of the
Hitex STR9-comStick eval board.
I attach the modified version of the above patch to match the files that
would be moved by the patch I've
Øyvind Harboe wrote:
It would be *great* to crack this problem once and for all.
It's been discussed in the past on the list.
4) That algorithm should/could use a *COMMON* set of commands
That is *common* to *ALL* targets.
For MIPS as well as ARM targets?
All targets.
My
24 matches
Mail list logo