Hi,
there are two TMPA targets: TMPA900 and TMPA910.
In the TMPA900 target, however, TMPA900 is mispelled as TMPA910.
Probably this was a copy paste error.
The attached patch fixes this. It was tested with a TopasA900
development board which uses the TMPA900.
CU
Michael.
From
This patch set fixes some general problems in the RLink interface driver.
Most importantly it fixes a performance bug that have been causing decreased
throughput.
Speed test on a STM32 Primer (STM32F103 platform with built in RLink) with the
following openocd.cfg
---
source [find
Indentation was inconsistent and some lines not indented at all. Quickfix
using Eclipse's auto-indentation.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c | 726 +++---
1 files changed, 363 insertions(+), 363
Remove unnecessary block scopes to reduce indentation level.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c | 203 +++---
1 files changed, 100 insertions(+), 103 deletions(-)
diff --git
dtc_queue.reply_index was wrongly being increased during out scans, causing
the queue to be sent before the out buffer was full. This patch increases
raw upload speed by 50% or so.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c | 16 +---
After the reply_index handling is fixed, there's no need to special case
the out scan.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c | 28 +---
1 files changed, 9 insertions(+), 19 deletions(-)
diff --git
After correcting the reply size counter, it should be safe to rely on it
for the number of bytes expected in the USB read, instead of reading the
endpoint maximum. This doesn't make things go any faster but it's nicer and
removes the local buffer.
Signed-off-by: Andreas Fritiofson
__FILE__ and __LINE__ are already printed using the log macros.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/src/jtag/drivers/rlink.c b/src/jtag/drivers/rlink.c
Add a helper function for running the queue if it would overflow otherwise.
Use it to simplify the queue fill level checks and optimize in a few cases
that would previously run the queue prematurely.
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/jtag/drivers/rlink.c |
This patch set enables targets to implement asynchronous algorithms that
can be run in the background while OpenOCD performs other tasks. It also
implements async algorithm support for ARMv7-M and enables it for the
Cortex-M3 target. The final two patches rewrites the stm32x flash driver
to use an
On supported targets, this may be used to start a long running algorithm in
the background so the target may be interacted with during execution and
later wait for its completion.
The most obvious use case is a double buffered flash algorithm that can
upload the next block of data while the
Split armv7m_run_algorithm into two pieces and use them to reimplement it.
The arch_info parameter is used to keep context between the two calls, so
both calls must refer to the same armv7m_algorithm struct. Ugly but works
for a proof-of-concept.
Signed-off-by: Andreas Fritiofson
Signed-off-by: Andreas Fritiofson andreas.fritiof...@gmail.com
---
src/target/cortex_m3.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
index 98a775c..a2f8b78 100644
--- a/src/target/cortex_m3.c
+++
Access the different flash banks' registers using a bank specific register
base and a register specific offset. This is equivalent but feels more
natural.
Some accesses were discovered that maybe should not be hard coded to bank0
registers. Add a note about that.
Signed-off-by: Andreas
Let the target algorithm be running in the background and buffer data
continuously through a FIFO. This reduces or removes the effect of latency
because only a very small number of queue executions needs to be done per
buffer fill. Previously, the many repeated target state changes, register
Hello Andreas!
Do you know what is the difference between JTAG (on Stm32Primer) and
SWD (on Stm32Primer2) RLink interface? Would they run on existing
driver? Do you have some kind of manual or technical specification?
Best regards! :-)
Tomek
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On 18 July 2011 00:46, Steve Bennett ste...@workware.net.au wrote:
If there is no way to make automake do this then I guess we have no choice.
I have pushed something similar to git.
Thanks for doing this, i have tested your changes and are just what we need :)
I am going to push the openocd
On 17 July 2011 10:18, Luca Bruno lu...@debian.org wrote:
make dist should use git2cl to genereate ChangeLog from git history,
populating the placeholder file in released tarball.
Still not working for srcdir != builddir
make[1]: Entering directory `/home/soliver/openocd/openocd-rel'
if test
On 18 July 2011 11:13, Andreas Fritiofson andreas.fritiof...@gmail.com wrote:
This patch set fixes some general problems in the RLink interface driver.
Most importantly it fixes a performance bug that have been causing decreased
throughput.
Speed test on a STM32 Primer (STM32F103 platform
On Mon, Jul 18, 2011 at 4:03 PM, Spencer Oliver s...@spen-soft.co.ukwrote:
On 18 July 2011 11:13, Andreas Fritiofson andreas.fritiof...@gmail.com
wrote:
This patch set fixes some general problems in the RLink interface driver.
Most importantly it fixes a performance bug that have been
On Mon, Jul 18, 2011 at 2:33 PM, Tomek CEDRO tomek.ce...@gmail.com wrote:
Hello Andreas!
Do you know what is the difference between JTAG (on Stm32Primer) and
SWD (on Stm32Primer2) RLink interface? Would they run on existing
driver? Do you have some kind of manual or technical specification?
Le 18/07/2011 16:25, Andreas Fritiofson a écrit :
Yes it's best to put these on hold for 0.5.0. It needs some testing on
the standalone RLink or other variants, I currently only have access to
STM32 Primers. Also more thorough testing in general. Anyone feels like
helping?
Hello Andreas,
I
On Mon, Jul 18, 2011 at 4:59 PM, Jean-Claude Repetto jcr...@mxm.eu wrote:
Le 18/07/2011 16:25, Andreas Fritiofson a écrit :
Yes it's best to put these on hold for 0.5.0. It needs some testing on
the standalone RLink or other variants, I currently only have access to
STM32 Primers. Also more
Hi,
I just could track down the following OpenOCD bug
https://sourceforge.net/apps/trac/openocd/ticket/34
to the following commit:
http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commitdiff;h=e3f3f60a02abfd836c555e84b997de778177bc83
Do you have any clue what could be
Peter Stuge kan du ringa för jag har försökt att nå dig sen 3 månader.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hi,
I'm not quite sure if my gdb is hosed up or if it is my openocd build.
OpenOCD version is Open On-Chip Debugger
0.5.0-dev-00959-gd6c42bf-dirty (2011-07-18-18:35)
Is there anything special that needs to be done to build openocd with
debug symbols turned on (-g)?
When I do a build, I see the
Sorry about the noise. I also found 500 emails in my inbox. The
problem is solved, so hopefully no more noise now.
//Peter
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
27 matches
Mail list logo
