When I tried it, it was OK. I didn't use a dongle though,
but the ZY1000 obviously. The ZY1000 is more like the
Abatron in that it actually runs OpenOCD onboard and
thus benefits from very low latency.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 /
Try reducing the jtag_khz, you may be on the edge of what
works.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
_
On 02/12/2010 12:21, Martin Davey wrote:
Hello,
I just upgraded to the latest CodeSourcery g++ lite, 2010.09-51. Recent
build of OpenOCD 02/12/2010.
After upgrading the compiler, I now get the error Remote 'g' packet is
too long. Output from arm-none-eabi-gdb:
file bin/xxx.elf
target remote lo
From: Spencer Oliver
When this config was updated in commit e3773e3e3d1f1ee0dbb0b69e8babe8419784d1c1
the old jtag declaration was not removed.
Signed-off-by: Spencer Oliver
---
tcl/target/stellaris.cfg |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/tcl/target/stella
Hi,
Communication using DCC seems very slow for me. Watching it gave me a
flashback to my first computing experiences using a ASR33 :) (a 110 baud
mechanical teletype for the youngsters).
I am trying to send arbitrary text messages to the debug console. I am
using a libdcc function. Unfortunatel
I'm attepmting board bringup on a series of boards. A few boards give me DR/IR
scan errors. Where, in my hardware, should I be looking for issues?
Thanks,
- Alex
$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
> reb_memtest
targ
Hi.
Our board has just bricked after an ESD. It no longer seems to boot up: does
not autoload from the SD card, nor show characters in the debug console, nor
turn on the LCD, not blink the GPIO leds like before.
It is an Logic 35x Development Kit (aka LogicPD OMAP3530 SOM LV):
http://www.logi
You're the expert.
If I don't hear anything, I'll merge it after a cooloff on the list
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and fl
Hi everyone,
Since a call went out for patches... been sitting on this for months. For some
reason, the xscale trace buffer is automatically disabled as soon as a break
occurs and the trace data is collected. This patch was a result of the
frustration of always re-enabling it, or else hitting a
Ok, the RAM seems to work correct. With the mww and mdw command I am able to
write the RAM and to read back the written values.
-Ursprüngliche Nachricht-
Von: Øyvind Harboe [mailto:oyvind.har...@zylin.com]
Gesendet: Donnerstag, 2. Dezember 2010 18:52
An: starkee...@gmx.at
Cc: openocd-de
On Thu, Dec 2, 2010 at 5:48 PM, Freddie Chopin wrote:
> On 2010-12-02 00:37, Antonio Borneo wrote:
>>
>> the patch involves file renaming.
>> Please add the flags "-M -C" to git-format-patch
>> With these flags the patch would be smaller, and would be easier to
>> follow the renaming.
>
> Sorry, c
Merged.
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
___
Openocd-de
On Thu, Dec 2, 2010 at 6:21 PM, Starkeeper wrote:
> How can I test if the working area is correct?
> The memorymap of my controller tells me that at address 0x4000 is a
> 64KB RAM.
mww + mdw?
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / Intern
How can I test if the working area is correct?
The memorymap of my controller tells me that at address 0x4000 is a
64KB RAM.
-Ursprüngliche Nachricht-
Von: openocd-development-boun...@lists.berlios.de
[mailto:openocd-development-boun...@lists.berlios.de] Im Auftrag von Michael
Schwing
Hi Freddie,
Thanks for your reply.
Spencer showed me the same link, but I have repeated it on the command
line, outside of the Eclipse environment.
Thanks,
Martin.
On 02/12/2010 16:50, Freddie Chopin wrote:
Update Eclipse to the most recent version (Helios SR1) and use the
most recent GD
Update Eclipse to the most recent version (Helios SR1) and use the most
recent GDB Hardware Debugging plugin.
Take a look at similar thread on arm-gnu list (CodeSourcery's mailing
list for Lite version).
4\/3!!
___
Openocd-development mailing list
O
On 2010-12-02 00:37, Antonio Borneo wrote:
the patch involves file renaming.
Please add the flags "-M -C" to git-format-patch
With these flags the patch would be smaller, and would be easier to
follow the renaming.
Sorry, can't do that... The patch you see was created in Windows with
TortoiseG
Spencer Oliver wrote:
> This does create an issue for all the luminary scripts however.
> They would need the 'reset_config srst_only' removing and this
> would break all the older scripts in the wild.
With a significant improvement to our data model I think it's OK to
break existing scripts. (The
On 02/12/2010 12:42, freddie_cho...@op.pl wrote:
"Spencer Oliver" napisał(a):
> As we know the current behaviour of cortex_m3 reset_config is to
> override the std 'reset_config' setting - this has undesired effects
> for people who expect srst for example to work.
>
> We need to
"Spencer Oliver" napisał(a):
> As we know the current behaviour of cortex_m3 reset_config is to
> override the std 'reset_config' setting - this has undesired effects
> for people who expect srst for example to work.
>
> We need to change that functionality then adding your patch would b
Search for "set architecture".
I'm working on a project where I'm getting too many registers
from the GDB server compared to what I need, and then
I set the architecture before I try target remote:
set architecture powerpc:common
target remote
--
Øyvind Harboe
Can Zylin Consulting help
On 02/12/2010 11:55, freddie_cho...@op.pl wrote:
"Spencer Oliver" napisał(a):
> I thought we has decided to work on the ability to make openocd a bit
> more reset aware for cortex-m3.
This is just for now, as maybe a new bug-fix release will be made.
> This fixes the case for some use
Hello,
I just upgraded to the latest CodeSourcery g++ lite, 2010.09-51. Recent
build of OpenOCD 02/12/2010.
After upgrading the compiler, I now get the error Remote 'g' packet is
too long. Output from arm-none-eabi-gdb:
file bin/xxx.elf
target remote localhost:2000
Remote 'g' packet is too
On Thu, Dec 2, 2010 at 1:05 PM, Drasko DRASKOVIC
wrote:
> Hello,
> is there a way to store a value of some memory location in a variable
> in Jim Tcl scrip.
>
> I tried like this :
>
> set UART_EN_HWRSTN 0x20004109
> set UART_EN_HWRSTN_CUR [mdb $UART_EN_HWRSTN]
>
> but it gives me just an empty st
Hello,
is there a way to store a value of some memory location in a variable
in Jim Tcl scrip.
I tried like this :
set UART_EN_HWRSTN 0x20004109
set UART_EN_HWRSTN_CUR [mdb $UART_EN_HWRSTN]
but it gives me just an empty string for UART_EN_HWRSTN_CUR (current
value of UART RESET register)
Many t
"Spencer Oliver" napisał(a):
> I thought we has decided to work on the ability to make openocd a bit
> more reset aware for cortex-m3.
This is just for now, as maybe a new bug-fix release will be made.
> This fixes the case for some users, but will break it for others.
For whom does that
On 01/12/2010 22:11, Øyvind Harboe wrote:
Any objections to this one?
I thought we has decided to work on the ability to make openocd a bit
more reset aware for cortex-m3.
This fixes the case for some users, but will break it for others.
For the moment i would say hold off, and lets come u
27 matches
Mail list logo