This patch adds Freescale DSP563xx and DSP563xx-ONCE (one chip emulation)
support.
---
src/target/dsp563xx.c | 875
src/target/dsp563xx.h | 73
src/target/dsp563xx_once.c | 116 ++
src/target/dsp563xx_once.h | 71
4 files
---
src/flash/non_cfi.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/src/flash/non_cfi.c b/src/flash/non_cfi.c
index f98b108..5169c53 100644
--- a/src/flash/non_cfi.c
+++ b/src/flash/non_cfi.c
@@ -280,6 +280,26 @@ static struct non_cfi non_cfi_flashe
---
src/target/Makefile.am |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/target/Makefile.am b/src/target/Makefile.am
index d00b0e4..a07de17 100644
--- a/src/target/Makefile.am
+++ b/src/target/Makefile.am
@@ -34,8 +34,10 @@ libtarget_la_SOURCES = \
$(A
---
src/target/target.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/target/target.c b/src/target/target.c
index 88931b5..3fafbb1 100644
--- a/src/target/target.c
+++ b/src/target/target.c
@@ -63,6 +63,7 @@ extern struct target_type cortexa8_target;
extern struct
From: Mathias Kuester
---
src/target/Makefile.am |6 +-
src/target/dsp563xx.c | 1037
src/target/dsp563xx.h | 88
src/target/dsp563xx_once.c | 124 ++
src/target/dsp563xx_once.h | 81
src/target/target.c|
Hello,
> So you wrote this from scratch?
Yes.
> I.e. are you the sole copyright holder?
Yes.
This work is based on the freescale documentation and included examples in this
documents.
List of documents:
AN1751.pdf
AN1839.pdf
AN1935.pdf
AN2074.pdf
APR25.pdf
DSP56300FM.pdf
DSP56321.pdf
DSP5632
The Format things are changed but no work on doc.
Am 11.12.2009 10:34, schrieb Øyvind Harboe:
> Work on the documentation and the other things that David & Zach(?)
> mentioned and post again.
>
>
___
Openocd-development mailing list
Openocd-developmen
From: Mathias Kuester
---
src/target/Makefile.am |6 +-
src/target/dsp563xx.c | 988
src/target/dsp563xx.h | 88
src/target/dsp563xx_once.c | 122 ++
src/target/dsp563xx_once.h | 81
src/target/target.c|
It is a custom board but should work with other configurations to. The JTAG is
a olimex ARM-USB-TINY.
I think a better target name (target struct) is "dsp563xx" instead of "dsp56".
Am 11.12.2009 11:37, schrieb Øyvind Harboe:
> On Fri, Dec 11, 2009 at 11:31 AM, Mathias K
Hello,
you can pass it to gdb with the -x start option. Put your stuff into e.g.
gdb.cfg and start gdb with
gdb -x gdb.cfg
Regards,
Mathias
Am 15.12.2009 16:51, schrieb Alain Mouette:
> Can anyone help me with this?
>
> To make single-step work better with IRQs and FreeRTOS in Eclipse, it
Hello,
here the patch to fix the crash and create the reg list.
Now another Problem with gdb:
User : 340 52745 gdb_server.c:106 gdb_last_signal(): undefined debug reason 6 -
target needs reset
Regards,
Mathias
Am 14.02.2010 07:33, schrieb David Brownell:
> On Saturday 13 February 2010, Aust
Hello,
i have tried the latest git version and some fundamental commands are not
working with lm3s:
> reset halt
JTAG tap: lm3s3748.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00,
ver: 0x3)
lm3s3748.cpu -- clearing lockup after double fault
... many many times the same line ...
lm3
Hello,
the command "soft_reset_halt" of the current git version of openocd segfault:
(gdb) bt full
#0 cortex_m3_assert_reset (target=0x818dba0) at cortex_m3.c:942
cortex_m3 = 0x818f118
swjdp = 0x818f1d0
reset_config =
jtag_reset_config =
retval =
27; connection from
Info : JTAG tap: lm3s3748.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part:
0xba00, ver: 0x3)
---
Am 17.12.2010 11:14, schrieb Spencer Oliver:
> On 17/12/2010 07:54, Mathias K. wrote:
>> Hello,
>>
>> the command "soft_reset_halt" of th
Hello,
okay i switched over to the scripts shipped with openocd and i got the crash
again. I cleand up the
source tree with depclean, compiled again and it is okay now.
My mistake, sorry.
Thanks,
Mathias
Am 17.12.2010 12:07, schrieb Spencer Oliver:
> On 17/12/2010 10:38, Mathia
Hello,
this patch add basic xds100v2 support. The settings are the result of the
protocoll reverse
engeneering with a simple usb logger. Tested with the TMS570 USB eval kit.
Regards,
Mathias
>From bcbe271b72833c4f0082af168c0cabe94de665d0 Mon Sep 17 00:00:00 2001
From: root
Date: Tue, 25 Jan 2
Hello,
i had the same error a while ago. Try to clean your repository (make distclean)
and recompile the
source.
Regards,
Mathias
Am 24.01.2011 23:08, schrieb Andreas Fritiofson:
> Hi all,
>
> Has anyone else problem with segfaults on current git? As soon as I
> issue a reset, openocd dies.
table
>From 6ad5ffe1b89054177a2eb3f9f5d4918d75ca64f7 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Wed, 26 Jan 2011 16:25:13 +0100
Subject: [PATCH 1/1] - fix the broken dap component base from the debug logic
on the tms570 cpu
---
src/target/arm
Hello,
this patch add the missing xds100v2.cfg file.
Regards,
Mathias
>From e8fcc18b51408965ceca70a8fd676925ec914aca Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Wed, 26 Jan 2011 17:35:56 +0100
Subject: [PATCH] - add xds100v2 configuaration file
---
tcl/interface/xds100v2.cfg |
Hello,
Am 27.01.2011 08:25, schrieb Laurent Gauch:
> The xds 100 is protected by a TI license.
>
> Integrating xds 110 in other software than TI software kill the license !!!
i cant find any information about this in my tms570 developer box or any
document on the cd. What kind of special licens
Hello,
this patch add the missing etm id to the dap info function.
Regards,
Mathias
>From cb16ba3e87ce192b74279e6b4017fee1a61e67f3 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Thu, 27 Jan 2011 09:16:09 +0100
Subject: [PATCH] add cortex-r4 etm id to dap info
---
src/target/arm_adi_v
Hello,
i have investigate some more time and i think the component base adresses are
okay. The problem that
i can see is the default selected AP in arm_adi_v5.c (its 0). In function
cortex_a8_examine_first
all mem_ap_read_atomic_u32 with the default selected AP (0) and adresses like
the CPUID
Hello,
On 29.01.2011 10:34, Michael Schwingen wrote:
Am 01/29/2011 05:53 AM, schrieb Phil Fong:
I have a Freescale 56F8013 which is a DSC from the DSP56800E family that I want
to flash. I am planning on connecting a FTDI FT2232H to the JTAG pins and wish
to flash it.
Where do I start looking
Hello,
this patch adds the missing cpu registers and the correct read/write register functions and fixed
most of the halt/step/resume issues.
Regards,
Mathias
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 10fd014..dea63a9 100644
--- a/src/target/dsp563xx.c
+++ b/src/target
Hello,
this patch add 24bit support to the target buffer functions and little/big
endian functions.
Regards,
Mathias
diff --git a/src/helper/types.h b/src/helper/types.h
index 04b0059..12b9515 100644
--- a/src/helper/types.h
+++ b/src/helper/types.h
@@ -116,6 +116,11 @@ static inline uint32_
Hello,
i think it's better to fix ahbap_debugport_init. I have the same wrong default
AP on cortex_r4.
/* Default MEM-AP setup.
*
* REVISIT AP #0 may be an inappropriate default for this.
* Should we probe, or take a hint from the caller?
* Presumabl
Hello,
this patch add commands to access to x,y and p memory. For run time optimization some local jtag
function was changed to static inline.
Regards,
Mathias
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 85d559a..4371d0a 100644
--- a/src/target/dsp563xx.c
+++ b/src/targe
Hello,
On 04.02.2011 01:38, Aaron Carroll wrote:
At a high level, I think it makes sense for functions to be explicit
about selecting an AP... I don't see any advantage to a "default".
I don't know if the AP always equal in a complete architecture or is this done at cpu vendor level.
For mem
Hello,
this patch increase the speed of the buf_set_buf function around 30%.
Regards,
Mathias
diff --git a/src/helper/binarybuffer.c b/src/helper/binarybuffer.c
index 3a16cce..e789e6f 100644
--- a/src/helper/binarybuffer.c
+++ b/src/helper/binarybuffer.c
@@ -133,19 +133,34 @@ void* buf_set_buf
Hello,
On 04.02.2011 17:31, Øyvind Harboe wrote:
On Fri, Feb 4, 2011 at 5:21 PM, Mathias K. wrote:
this patch increase the speed of the buf_set_buf function around 30%.
how do you arrive at 30%?
There is no more slow math used in the iteration like "/" or "%". On
Hello,
okay the patch has a little bug. I have not set the correct start pointer of the input and output
buffer.
Also i have checked the input of this function and in many cases a simple byte
copy is possible.
I have added this check now and is it possible the buffer is copied byte by
byte an
sorry, wrong file ...
diff --git a/src/helper/binarybuffer.c b/src/helper/binarybuffer.c
index 3a16cce..08e149a 100644
--- a/src/helper/binarybuffer.c
+++ b/src/helper/binarybuffer.c
@@ -133,19 +133,48 @@ void* buf_set_buf(const void *_src, unsigned src_start,
{
const uint8_t *src = _src
Hello,
On 07.02.2011 03:54, Aaron Carroll wrote:
On A8/omap35xx and A9/omap44xx, the CPU CoreSight component is on AP 0
(an APB-AP). However, for both these platforms we do memory accesses
on AP 1, which is an AHB-AP. One advantage of this is the core does
not need to be halted to access memory.
Hello,
On 07.02.2011 03:57, Aaron Carroll wrote:
On 04/02/11 17:00, Øyvind Harboe wrote:
Maybe DAPs should exist independently of JTAG and
targets and targets should refer to the DAP relevant
to that target?
Agreed, but then how does one discover the DAP relevant to a TAP.
Suppose core0 is on
Hello,
On 07.02.2011 09:09, Øyvind Harboe wrote:
What impact would it have to make this an
inline fn?
I think there is no need to declare this "big" function as inline. This will only increase the code
size.
I see some functions in the jtag/interface.c file with a very small body that could
Hello,
On 07.02.2011 09:27, luca ellero wrote:
On 07/02/2011 3.54, Aaron Carroll wrote:
On 04/02/11 17:31, Mathias K. wrote:
Hello,
On 04.02.2011 01:38, Aaron Carroll wrote:
At a high level, I think it makes sense for functions to be explicit
about selecting an AP... I don't se
Hello,
On 05.02.2011 10:43, Øyvind Harboe wrote:
What sort of CPU did you run the tests on?
Which test? The target cpu/mcu or my system cpu?
Let me know when the patch is ready to be committed. I suppose
it could need a bit of coolof .
I think its fine.
Regards,
Mathias
___
Hello,
On 08.02.2011 15:37, Tom Schouten wrote:
However, when restarting OpenOCD after USB replug it does work like normal. Is
there a way to make
this recover inside OpenOCD, or otherwise to simply exit the application so it
can be restarted
automatically?
Yes, you can exit openocd. Try the
Hello,
is there any way to determine the current and maximum queue size before a
jtag_execute_queue() has
to be executed ?
Regards,
Mathias
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/lis
Hello,
in app. note AN1839 (dsp563xx) its 3 ;-). In DSP56300FM and AN2074 they use the
correct number 5.
Regards,
Mathias
Am 10.02.2011 20:25, schrieb Phil Fong:
> Hi,
> I've been working on Rodrigo on adding support to flash Freescale dsp56800e
> devices and have been looking at the ds
Changes:
- delay jtag queue excecution to decrease memory read/write times
- fix an early queue excecution in once interface
diff --git a/src/target/dsp563xx.c b/src/target/dsp563xx.c
index 4371d0a..9bfb9a1 100644
--- a/src/target/dsp563xx.c
+++ b/src/target/dsp563xx.c
@@ -29,8 +29,6 @@
#include
Changes:
- declare tap_set_state_impl, tap_get_state, tap_set_end_state,
tap_get_end_state as static inline,
this will decrease the calling overhead for this status getter and setter
functions
diff --git a/src/jtag/interface.c b/src/jtag/interface.c
index 1ed4512..8d5d514 100644
--- a/src/jtag/i
Hello,
i think this patch make sense because the functions are called very often
(column calls in the
profile data) and do a little bit more then nothing.
Am 11.02.2011 07:29, schrieb Øyvind Harboe:
> I don't have any objections to this particular patch, but if we
> have to start doing tweaks at
Hello,
Am 11.02.2011 10:01, schrieb Øyvind Harboe:
> What kind of CPU are you running OpenOCD on?
It's a Intel T7200.
Regards,
Mathias
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinf
Hello,
Am 11.02.2011 10:17, schrieb Øyvind Harboe:
> How about rewriting clock_tms then?
>
Because the used time? This session was to short (some seconds) to get a
meaningful time statistic.
Regards,
Mathias
___
Openocd-development mailing list
Ope
On a memory read/write access the queue has always flushed at the end.
But if i read some more data without a queue excecute in the middle and only at
the end i get this
error:
Error: ftdi_write_data: usb bulk write failed
Error: couldn't write MPSSE commands to FT2232
I think there are to much
Hello,
Am 11.02.2011 16:21, schrieb Mathias K.:
> On a memory read/write access the queue has always flushed at the end.
>
> But if i read some more data without a queue excecute in the middle and only
> at the end i get this
> error:
>
> Error: ftdi_write_data: usb bulk
Hello,
this patch add 2 functions to set data bits high/low byte.
Regards,
Mathias
>From b1cdc2056c85b9798d4f2ffe6a5b2f3f2f8fef05 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Sun, 13 Feb 2011 13:21:42 +0100
Subject: [PATCH] - add functions for ft2232 set data bits high/low byte comm
rom b1cdc2056c85b9798d4f2ffe6a5b2f3f2f8fef05 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Sun, 13 Feb 2011 13:21:42 +0100
Subject: [PATCH] - add functions for ft2232 set data bits high/low byte command
---
src/jtag/drivers/ft2232.c | 373 +++--
1 files changed,
Hello,
the mpsse buffer preparation and send functionality is done in:
ft2232_set_data_bits_low_byte
ft2232_set_data_bits_high_byte
You only need to deliver the port value and direction to this functions. Thats
all.
Regards,
Mathias
Am 14.02.2011 10:36, schrieb Laurent Gauch:
> Why removin
No, i need to change this. Anyway the overflow of the command read buffer size
in ft2232 should be
fixed (patched) first. I think in some circumstances this can happen again (i
have not seen this
yet) and this function need some more work to avoid this case in the future.
Am 14.02.2011 15:35, s
Hello,
you can try configure with "--enable-verbose-jtag-io". All the jtag
input/output is done in interface.c.
Regards,
Mathias
Am 15.02.2011 02:28, schrieb Rodrigo Rosa:
> Hi,
>
> We've been trying to communicate via JTAG (through a signalyzer H2)
> with a freescale 568013.
> Modifying t
Yes.
Am 14.02.2011 15:35, schrieb Øyvind Harboe:
> Should this patch be merged?
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
:
> Should this fix be merged?
>
> Any objections?
>
> Could you write a patch with a better commit comment?
>
> Thanks!
>
From 684ffa06a3e18495d6653d6e89f2a058636bbd89 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Tue, 15 Feb 2011 16:59:23 +0100
Subject: [PATCH 1/2]
Changes:
- remove pipeline context, use once register instead
- fix wrong register write in resume and step function
- add more conditional branch handling
Regards,
Mathias
>From 996a0c10623ed05e5bb3187b9f2134e51d279887 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Tue, 15 Feb 2011 20:17
communication errors
- check the static pattern in jtag status to verify that the value is almost
correct, this check
fail if no target is present
Regards,
Mathias
>From 10c511d919ad5e9ea1c5c82ba4e845fd6357d945 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Wed, 16 Feb 2011 15:00:06 +0
Hello,
i would inform you that make failed on my site with the make switch-jX and X
greater than 1.
Regards,
Mathias
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-develop
se edit for a commit, you
> can modify the changes for that commit or simply change the commit
> comment:
>
> git commit --amend
>
>
> The format of a commit comment is(by convention):
>
> topic: short descript
>
> longer description
From 9132f87664eeb9021d0
Hello,
i try to work with a propritary software and a openocd gdb connection to my
dsp563xx target. This
software sends a very important command "qset memspace 3". This command switch
between the different
target memory types (p,x,y,l) before a data upload/download.
I have tracked down the gdb
Hello,
Am 17.02.2011 13:17, schrieb Edgar Grimberg:
> What does
>
> make --version
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPO
Looks like the tcl function is not called:
Debug: 355 26143 gdb_server.c:2183 gdb_input_inner(): received packet:
'qRcmd,736574206d656d73706163652030'
parameter for command_run_line() -> "qset memspace 0"
User : 356 26147 command.c:707 command_run_line(): 0
Debug: 357 26147 gdb_server.c:388 gdb_pu
is then
"set memspace 0" and
the command "set" is called.
Is there any way to access the value "memspace" from c ?
Regards,
Mathias
Am 17.02.2011 20:00, schrieb Mathias K.:
> Looks like the tcl function is not called:
>
> Debug: 355
Am 18.02.2011 08:19, schrieb Øyvind Harboe:
> On Fri, Feb 18, 2011 at 8:12 AM, Mathias K. wrote:
>> Okay, i have found the issue. If i use the monitor command from gdb i
>> receive the string "qqset
>> memspace 0", with an extra "q" in the prefix. This
This works, i need the global command context to access this variable from c:
/* from openocd.c */
extern struct command_context *global_cmd_ctx;
/* get the interpreter */
Jim_Interp *interp = global_cmd_ctx->interp;
Jim_Obj * memspace = Jim_GetGlobalVariableStr(interp,"memspace", JIM_NONE);
if
Hello,
this patch add rudimentary gdb support to the dsp563xx target.
Regards,
Mathias
>From a0e603b114f4a7bcfab1ba1fd96693947d4d573a Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Sun, 20 Feb 2011 11:12:53 +0100
Subject: [PATCH 1/1] dsp563xx: rudimentary gdb support
This patch
Hello,
the target_write_buffer and target_read_buffer functions try to align the
memory read/write access.
This is wrong for the dsp563xx target, it is not possible to read a byte are
half word on a odd
address. On every memory address there are 3 bytes of data.
Is there any chance to add a co
Hello,
i see two possible solutions.
The first is to add a bit option to the target struct that define the supported
memory access like
8,16,32 bit (default 8/16/32) and target_write_buffer/target_read_buffer would
align in respect to
this value. I don't prefer this.
The second is to add a tar
Hello,
this patch add the risc (default) and harvard architecture to the target
structure. Currently
this patch only affect the memory read/write functions.
Regards,
Mathias
From dbfc2e3b9473a9cfb48c3e6e651be7152f32748b Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Thu, 24 Feb 2011 09:31
Hello,
i have done more tests on this issue and i have create the patch bellow.
Regards,
Mathias
>From f2ecac695568717b953c0a323ac683e28108f11f Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Thu, 24 Feb 2011 12:53:52 +0100
Subject: [PATCH] ft2232: fix possible read buffer overflow
T
Hello,
Am 24.02.2011 22:27, schrieb Michael Schwingen:
> Am 02/24/2011 09:36 AM, schrieb Mathias K.:
>> this patch add the risc (default) and harvard architecture to the target
>> structure. Currently
>> this patch only affect the memory read/write functions.
> I
Hello,
Am 25.02.2011 14:38, schrieb Michael Schwingen:
> Mathias K. wrote:
>> I think you can't simple abstract this with 8/16/24/32bit access, because in
>> my case the data bus
>> has always a 24bit width and the address bus increment is always one (one
>>
Am 25.02.2011 17:54, schrieb Michael Schwingen:
> Mathias K. wrote:
>>
>> Am 25.02.2011 14:38, schrieb Michael Schwingen:
>>
>>> Mathias K. wrote:
>>>
>>>> I think you can't simple abstract this with 8/16/24/32bit access, because
&g
Hello,
read http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT4232H.pdf
page 9. Looks like a
wrong hardware implementation. It is not possible to switch any jtag pin.
Regards,
Mathias
Am 02.03.2011 13:22, schrieb Jean-Christophe PLAGNIOL-VILLARD:
> Hi,
>
> I'm currently ad
Hello,
this message should be only visible if the debug output enabled. If you have
usb read/write problems
sometimes, this is the point you have to look.
Regards,
Mathias
Am 03.03.2011 10:19, schrieb Jon Povey:
> Since 6ddcee7d20ee873f1c214736c22f29d9781dded4
>
> When I try to read memory,
Hello,
this patch fix the log message and change the log output to debug.
Regards,
Mathias
>From 1eea6ab88e31e912eea0f4b14c7317329fa6 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Thu, 3 Mar 2011 10:28:21 +0100
Subject: [PATCH] ft2232: fix log message and change log output to de
Hello,
this patch add a target memory alignment option.
Regards,
Mathias
>From 7cafbb5b454fb79f36368e9b8c3a62b486f6c024 Mon Sep 17 00:00:00 2001
From: Mathias K.
Date: Thu, 3 Mar 2011 11:01:46 +0100
Subject: [PATCH] target: memory alignment option
Add a target option to enable/disa
Hello,
the current git head failed to compile jimtcl. I use latest cygwin and
following configure options:
./configure --enable-maintainer-mode --disable-werror --disable-shared \
--enable-ft2232_ftd2xx \
--with-ftd2xx-win32-zipdir=/cygdrive/c/data/cdm/
Last compiler line:
gcc -g -O2 -o jim
I have append it, it is only the linker output.
Am 10.03.2011 11:47, schrieb Peter Stuge:
> Mathias K. wrote:
>> Any hints to solve this problem?
>
> Please send exact copy of error messages, otherwise any diagnosis is
> impossible.
make all-recursive
make[1]: Entering dire
Hello,
the correct fix should be:
((uint32_t*)buffer)[i+1] = ((uint32_t*)buffer_x)[i1];
This function merge buffer_y and buffer_x into buffer.
Regards,
Mathias
Am 15.03.2011 15:08, schrieb Øyvind Harboe:
> found by inspection, not confirmed.
>
> Signed-off-by: Øyvind Harboe
> ---
> src/t
Hello,
Am 16.03.2011 20:19, schrieb Drasko DRASKOVIC:
> However, trying to load a bigger image function
> mips_m4k_bulk_write_memory() is called an fails in
> mips32_pracc_fastdata_xfer(). So, making mips_m4k_bulk_write_memory()
> to fall straight away to simple mips_m4k_write_memory(), like in
>
Yes, thanks.
Am 15.03.2011 16:32, schrieb Øyvind Harboe:
> better?
>
>
>
>
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Hello,
for performance reason i would change the chunksize in src/flash/nor/tcl.c from
a hard coded value
to a option/parameter with a default value of the old hard coded value (1024).
Currently i use a
value of 32*1024.
Can anyone give me a suggestion to add this to the configuration file,
pre
I don't know if this high value break any other flash driver. But this is okay
for me.
Am 17.03.2011 08:57, schrieb Øyvind Harboe:
> I hate options. Can't we just set the "right" value or figure it out?
>
>
> Crank it up real high? 128/256kBytes?
>
>
>
>
_
Hello,
Am 17.03.2011 13:45, schrieb Drasko DRASKOVIC:
> 1) In openocd/src/target/mips_m4k.c we can see that target endianess
> is checked and treated only mips_m4k_bulk_write_memory() in and not
> mips_m4k_write_memory() and mips_m4k_read_memory(). Why is this so ?
> (It leads to wrong SDRAM setu
Hello,
the send buffer looks okay. Maybe this is a timeout problem. Do you use the
d2xx or ftdi library?
Regards,
Mathias
Am 17.03.2011 13:14, schrieb Drasko DRASKOVIC:
> 3174056 Debug: 3174389 188209 ft2232.c:809 ft2232_send_and_recv():
> write buffer (size 18):
> 3174057 Debug: 3174390 1
I think you should reduce your clock speed first.
Am 17.03.2011 16:27, schrieb Drasko DRASKOVIC:
> clock speed 6000 kHz
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-developme
Hello,
i can't reproduce your errors. The libftdi and d2xx works like a charm here
(linux/windows). Error 4
means IO Error. I think you have carefully check your USB cables and your
hardware. If you work with
linux you can try "dmesg" to get some reports about hardware problems,
specially usb.
Am 29.03.2011 15:16, schrieb Drasko DRASKOVIC:
> Xiaofan,
> thanks for this confirmation.
>
> We can say that we identified the issue.
>
> However, it is still strange that the issue is not reproducible by Mathias...
>
> Mathias,
> are you sure that you used latest D2XX, version 1.0.4 ?
No, not
Yes, but works with the latest windows d2xx.
Regards,
Mathias
Am 29.03.2011 16:21, schrieb Drasko DRASKOVIC:
> On Tue, Mar 29, 2011 at 4:03 PM, Mathias K. wrote:
>> Linux: d2xx 0.4.16-r1
>
> Yes, it works for me also with 0.4.16. Problem is in new D2XX 1.0.4.
&g
Hello,
please tell us the version of the ftd2xx or read the ml.
Regards,
Mathias
Am 31.03.2011 19:14, schrieb Gwennaël Arbona:
> Hi,
>
>
> I am having a bug using OpenOCD 0.5.0-dev-00815-g8d338f3 (just compiled).
> I am working on Debian Squeeze 32 bits. I am using ftd2xx from FTDI.
> So I
I was able to link openocd against libjim. There is only a problem to link
jimsh against libjim.
Regards,
Mathias
Am 02.04.2011 03:10, schrieb Steve Bennett:
> On 10/03/2011, at 9:20 PM, Mathias K. wrote:
>
>> I have append it, it is only the linker output.
>>
>
Am 06.04.2011 18:58, schrieb Michael Schwingen:
> Am 04/06/2011 05:45 PM, schrieb Laurent Gauch:
> However, if the ULINK is basically an EZ-USB chip which downloads its
> code via USB, using the ULINK protocol would also mean we would have to
> use Keil's firmware, as it needs to be downloaded ever
Hello,
Am 06.04.2011 19:53, schrieb Martin Schmölzer:
> On Wed, 2011-04-06 at 17:45 +0200, Laurent Gauch wrote:
>
>> The EZ-USB gives access to USB but not to the ULINK interface. Right ?
>
> The ULINK consists of the EZ-USB microcontroller, an SRAM, an EEPROM and
> level shifters. There's even
Hello,
sometimes i see this messages if my jtag cable (flat cable) not correct
connected to the target
board. But this is a cable issue.
Regards,
Mathias
Am 12.04.2011 14:44, schrieb Sergio:
> Info : JTAG tap: lm3s2776.cpu tap/device found: 0x3ba00477 (mfg:
> 0x23b, part: 0xba00, ver: 0x3)
Hello,
i only have test it with this configuration, no more investigations. I think
the biggest problem is
the flash write functionality.
Regards,
Mathias
Am 13.04.2011 20:05, schrieb Ingo Hornberger:
> Mathias K. writes:
>>
>> [...]
>> Anyway, i was able to connect to
Hello,
there are several mechanism to protect or unprotect the sectors
(factory/customer). If the "Secured
Silicon Sector" locked you need 12V at the reset pin to execute the "Temporary
Sector Group
Unprotect" command. If the "Secured Silicon Sector" not locked you are able to
unlock the secto
Hello,
please tell us more about your target platform.
Regards,
Mathias
Am 02.05.2011 18:06, schrieb Jie Zhang:
> Hi,
>
> I encountered an issue when using OpenOCD with GDB. After GDB connects to
> OpenOCD and halt the
> target, "info reg" command returns all zeros for all registers. I took
our reply!
>
> I'm adding a new target to OpenOCD. But I think all existing targets in
> OpenOCD have this issue.
> Maybe I missed something...
>
> Jie
>
> On Mon, May 2, 2011 at 12:13 PM, Mathias K. <mailto:kes...@freenet.de>> wrote:
>
> Hello,
I think gdb will get the register list and then, maybe depending on used debug
application, all
register values.
But we should remember that some/all functions in the current implementation,
that need a target
register to work, simple doesn't check if a register already stored or not.
They only
Am 03.05.2011 22:12, schrieb Jie Zhang:
> I'm not familiar with ARM targets. So I'm not very sure. My guess is
> this can also improve performance on ARM targets but they needs be
> adapted to this lazy read usage.
Your blackfin is fast enough. This "read usage" only affect you if you rape the
st
1 - 100 of 135 matches
Mail list logo
