rick This doesn't change the pointer returned by cmd_queue_alloc() at all.
the problem I believe is the *NEXT* allocation that is failing, after an
odd-sized request, you get an odd aligned pointer.
Two odd requests - should give you an even.. (sort of, not exactly, it
has to be 4 bytes
Øyvind If the issues relate [snip] a problem we'll be fixing in
[snip] 3-6 months,
Øyvind [dcc] It's only 24 bytes, what's the downside?
(A) Good: If enabled, aligned, and (size 128 byte) DCC use is automatic.
(B) Missing: There is no protection for over-writing it self
(C) Missing: There is
Spen/Oyvind,
{or somebody else...}
Can one of you help me with the str9 issues?
I'm sort of stuck.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Rick,
I don't have an arm11 target to test with.
I believe you have an ARM11 target... can you confirm the arm11 still
works after my changes?
[or anybody else out there who has one...]
-Duane.
___
Openocd-development mailing list
rick Then you probably haven't seen 'make distclean' either
Oh I have - and things deep in the bowels of GDB and GCC In fact, I
have my own googlewhack
So that -it remains a google wack, I must spell it out... goto google
and type my name, the digit 1, a space, and the word y a i p.
Sometimes
For those who do not know - I am a new commit person for OpenOCD.
I have just committed a large (in size) but small (in scope) patch. The
patch is 300K, I did not attach it.
There may be some bumps in the road, they should be sorted out
*QUICKLY*.
If you are reading this and
* you are a
I write this as a separate (from my Commit) email hoping it stops some
email and help you solve some immediate problems.
-Duane.
The command:
jtag_device IRLEN IRCAPTURE IRMASK IDCODE
Has been removed.
The quick fix is as follows.
set _CHIPNAME mychip
set _CPUTAPID 0.
What is the required work area size?
I know that having a work area and the DCC can give a 5x to 10x download
speed improvement.
-Duane.
Reasons for my question is the following:
=
For example some chips have lots of ram. Some chips do not have much.
What happens when the download goes
duane What is the required work area size?
rick None. The flash methods
Actually the flash methods do need space - otherwise they will not work.
Thank you for pointing out the flash - I had forgotten about that.
There are two sides to the problem.
(A) flash programing - I had
oyvind [commit - of earlier stuff]
spen The docs still talk about the old commands - chapter 4.7
duane FYI - I am in the process of updating docs... And removing the
jtag_device command - replacing it with jtag newtap. I will try to
address some of these issues.
I have a *MASSIVE* update
rick Is there a practical reason why the daemon cannot be started
unless an interface has been specified?
[snip]
oyvind I've did a lot of work a year back to support connecting to
powered down targets
[snip]
I would add the SPI/I2C/etc type changes would have *NO* targets.
Today, OpenOCD
duane [built in console]
dominicThat would be nice, but when I decided to go with a telnet
console it wasn't exactly easy finding a cross-platform compatible
console. Do you have something particular in mind?
UrJtag has exactly this now. I'd look there first.
Baring that
(A) Linux: gnu
rick Are there other syntax changes that should be made before 1.0? If
so, what are they?
My changes to support enable/disable jtag taps is a non-trivial change.
I have it working - I'm testing things as I work through them.
BY WORKS:
I mean - jtag identifies.
I can type halt, reset,
Spen wrote:
I have committed the following patch.
For some reason the files on svn were corrupt - these are the only ones i
could find.
I suspect the following:
Somebody has been using something like MSWORD and/or another Text -
not ASCII-TEXT editor on source code.
There are a number of
andreas Sorry for all the removed whitespace at the end of lines,
courtesy of Eclipse.
According to the link below, this is an editor preference.
http://dev.eclipse.org/newslists/news.eclipse.tools.cdt/msg17143.html
___
Openocd-development
oyvind are you keeping two lists? One list for active and one for all taps?
One list. With an p-enabled element.
Duane 2) There is a ghost variable (that holds the length of the list)
oyvind rick [ this is good for performance ]
Agh... Really? I suspect both of you have fallen into the
Mikael Rosbacke wrote:
Hello!
Seems I'm the only one crazy enough to try to run a uClibc based
distribution on x86. (I can see the response, What's the point?)
?Wrong mailing list?
This is OpenOCD..
___
Openocd-development mailing list
All,
I've been working some on support for the beagleboard (oma3530) - you've
seen quite a bit of traffic on the mailing list about this.
I need to break these changes in two parts.
One thing that is shaking out of this is the removal of the tap index
idea, and going with a uniform tap name
spen release will be for both x86 win32 (mingw) and linux
I would add a Cygwin build.
Only because - often some development environments are _cygwin_ in
addition to mingw
-Duane.
___
Openocd-development mailing list
duane [long description of how to do this]
kees The kind of changes you are talking about seams very far away from
anything I could help with.
That's ok - feed back testing is also very helpful.
-Duane.
___
Openocd-development mailing list
All -
I'm doing some work that with a new jtag tcl command to help support
beagle board.
I need to deal a little bit with how taps are ordered. This also effects
the target command stuff some what.
I have a general idea sort of worked out - and need some input/feed back
if the scheme
==
duane # Example: Declare a chip, for example some Xilinx FPGA
duane jtag newtap xilinx -chip xilinx -ir-length 6 -ir-capture
-ir-mask
rick [I don't like chip]
I prefer chip for one reason. Physically that is what is present on
the board.
However, based
duane # Example: Declare a chip, for example some Xilinx FPGA
duane jtag newtap xilinx -chip xilinx -ir-length 6 -ir-capture
-ir-mask
rick [I don't like chip]
duane I prefer chip for one reason. Physically that is what is
present on the board.
rick That's a pretty
Steve Franks wrote:
I have code lying around for read/write of 'standard' SPI I2C
eeproms (at24Cxyz [i2c] and at25Cxyz [spi]). The interface is a
separate file from the protocol, so it should be applicable. It's up
for grabs if someone goes down this road. All the 8-bit guys have
Øyvind Harboe wrote:
Looks good to me.
I saw that your scheme above also handled reordering the
chain, but didn't quite see how you achieved that.
I presume that reply was to me... the mail thread order got wacky.
It does not really reorder the chain - but it could easily do so.
The
Tim Eccles wrote:
Hi
I have been inching my way into getting OpenOCD Serial Wire JTAG (SWJ)
working on the ARM Cortex-M3.
Looking around I get the sense that quite a few people have looked at
SWJ and I would like to pull together any unfinished contributions that
are out there.
So
Steve Franks wrote:
The folks over at urjtag (http://www.urjtag.org/) are doing this for
svf (but not xsvf). Might be a good learning tool. Seems to program
all my xilinx stuff...
Might be opportunities to merge or share code as well. If you add
urjtag and openocd together, I think you
[the docs] might get out of date. The docs would of course refer to
the TCL commands to get the most current list.
FYI - the command to do that exists today.
target types
arm7tdmi arm9tdmi arm920t arm720t arm966e arm926ejs feroceon xscale
cortex_m3 arm11 mips_m4k
-Duane.
Øyvind Harboe wrote:
Currently each target gets it's own GDB server.
However, I'm thinking that it would be better in most cases to
have each CPU represented as a thread in GDB. That way only
one debug session needs to be opened.
This would be for CPUs of the same type that share memory.
John McCarthy I've got an ARM926EJ-S
A bit more detail about the actual chip would be helpful. (arm926 is the
core) but who makes the chip?
Only thing I find that names flash integration unit is a freescale thing.
John McCarthy Could anyone give me a high level description on what
would be
Laurentiu Cocanu wrote:
Hi
I integrated READ_TARGET_COMMENT.txt content into openocd general
documentation (outputted as openocd.pdf).
Thank you for doing that for me! I really appreciate it.
-Duane (they guy who was to lazy to do that)
___
duane Can we get confirmation about how the JRC works in OMAP?
kees I am sure there must be exceptions to your rules but I guess that
having this 3rd state will make it very easy to implement what we need
right now
keesWhy are those assumptions important? Why is is hard to insert an
element
Øyvind Harboe wrote:
Here is a thought:
- define jtag device/target num to be a unique id that has nothing
to do with the ordering of targets/jtag devices
This exists now for the TARGET - not for the TAP chain.
(ie: remember the [new_target_name] thing?)
- the jtag device chain can then
Fabio I am trying to write to MX31 (ARM11) CP15 registers
Fabio using OpenOCD. The commands I want to perform are:
Fabio setreg @CP15_CONTROL=0x00050078
[snip]
Georg [it works, using the mcr/mrc commands]
fabio Thanks. It worked as follows:
fabio monitor arm11 mcr 1 0 0 15 2 4 0x00050078
fabio
spen [confused about reset events]
oyvind [ go read the source code ]
This needs a bit more documentation :-(
In spens case, yes, I think something did change.
I think SPEN is thinking reset - plain - halts the CPU. But it does
not - it does reset run.
I think that decision - which happened
Øyvind Harboe wrote:
A target event wouldn't work terribly well here, as OpenOCD is founded
on the false assumption that the JTAG chain never changes throughout OpenOCDs
lifespan.
Yes, but - I think - the JRC only allows insertions and deletions in a
specific order. Not total and random
Attention Beagle Guys,
Can we get confirmation about how the JRC works in OMAP?
Is the following assertion true?
When a TAP is enabled, it is always enabled at a FIXED position within
the chain?
To describe it another way - Assume there are 3 taps.
(1) ICE Pick - the JRC
(2) An ARM
Øyvind Harboe wrote:
Retired old reset code according to plan.
:-)
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Øyvind Harboe wrote:
But if you want to break all target_script - commands - go ahead - they
will all be broken when you do that.
The patch does not break target_script command, it uses reset-init
instead of old-post_reset.
So assuming that target_script is not broken, is there a
A while ago - Simon Qian had a problem with IAR tools - a portion of
that fix was not checked in.
That problem dealt with GDB sometimes not ACKing correctly - the +
being dropped.
Today - I find I can sometimes have the identical problem with GDB - but
in a slightly different location :-(
Øyvind Harboe wrote:
DRAM makes this more complicated in that non-working ram
mode has to be supported.
Obviously with DRAM *quantity* of RAM is even less of a problem.
Why must non-working-ram mode be supported?
___
Openocd-development
Øyvind Harboe wrote:
I'd like to stick to C (and GCC) as the tool to describe
target algorithms.
For MIPS/ARM this means position independent code
w/some clever entrypoint handler.
Assuming all interesting target types can generate position
independent code: why would we want to introduce
Michael Schwingen wrote:
duane Assertion:
duane During flash programing, openocd controls the world and the chip.
duane And - there is ram to be had some where that openocd can use.
michael That depends. Getting DDR2 SDRAM controllers initialized can be
a quite tedious task,
michael so you may
John McCarthy wrote:
I was thinking along the same lines. This way we write an opcode stream
definition for each flash type which works for all targets (with
external flash). And for each target implementation we provide an
opcode interpreter and a fast buffer transfer mechanism. The target
Fabio Estevam wrote:
Hi,
I have researched in the list archives and have seen some attempts to get
MX31 support under OpenOCD.
Has anyone succesfully used OpenOCD with MX31 processor? If so, which JTAG
hardware have you used?
Thanks,
Fabio Estevam
I do not know about the I/O
somebody I'm not convinced that your JTAG chain is configured correctly
somebody or that your JTAG interface is able to communicate with the
device.
somebody ARM11 is finicky
I believe this is exactly the ARM 1176 chip.
Here is why.
Info: JTAG device found: 0x2b900f0f (Manufacturer: 0x787,
duane (A) Take a page from the arm-semi-hosting.
oyvind [snip] What's arm-semi-hosting?
Also see this:
http://www.arm.com/support/faqdev/1494.html
ARM defined a specific SWI instruction SWI number that allow the
debugger to communicate with the host system via the debugger.
Support for
Michael Schwingen wrote:
First, I think the target code should stay as small as possible, because
there may be targets where very little RAM is available for the code.
I disagree, I think we always have 4K of ram, here's why:
Generally:
There are two classes of devices.
1) Those
Øyvind Harboe wrote:
There is an objloader in eCos w/a suitable license model.
But perhaps we can do position independent code on all targets w/GCC?
If it requires a obj loader we have made something to complex.
-Duane.
___
Openocd-development
Michael Schwingen wrote:
The C code reads its parameters directly from params, and writes its result
there.
Agreed, sounds simple. But I do not think code-lets is the right idea.
It is too simplistic.
Reasoning:
Most flash sequences are simplistic, there are no more then 10 to 20
commands.
Michael Schwingen wrote:
Now the question is: can we generate position-independent code using
gcc on all platforms?
But remember, today OpenOCD supports exactly 2 targets: ARM and MIPS
(sort of).
For ARM, this is simple. In C - might be tough to coax the compiler into
working the way you
Oyvind/Georg,
I see you both are talking about the flash algorithm support in openocd.
There is a few tricks that I see that could be done to simplify the
situation.
To communicate with a flash driver - first - do not call it a flash
driver.
Call it an 'execution engine' you'll understand why
Kishore wrote:
I would appreciate anyone sharing with me the gdbinit script that they use
with openocd and Atmel's evaluation board. I have a feeling that with newer
openocd revisions the flash write has become slow and i see several errors on
the command line when i use my old gdbinit
Øyvind Harboe wrote:
old-post_reset is the most important event that just about anyone
writing a target configuration script will encounter.
How about simply renaming this event to indicate that it is
still fully supported and recommended rather than something
old and nasty to be ignored?
OK.
Update all the target event scripts then?
You mean change the scripts supplied with openocd - then yes, they
should switch to the new system.
But we should not get rid of the old-names because others may have
customzed scripts locally
and there is on means to update those.
-Duane.
dswei wrote: [all about debugging with virtual memory problems]
I believe you understand the basic idea, let me explain a bit more.
FIXED LOCATION SOLUTION
(A) Some operating systems - have a *FIXED* location for a few
functions. For example - if you TFTP boot your file across the network,
the
dswei wrote:
Hello, all.
A program, before it can run at it's runtime address, it has to configure
the memory, copy itself to the memory,
or enable the MMU; after these, it can run at it's runtime address.
My question is, how can I debug it with OpenOCD and gdb, when it does not
run
But this lead me to the conclusion that the wiggler parport has no
analog problems (aside from the perfectly digital levels at the scope).
So I've looked into jtag/bitbang.c and read that comment in bitbang_scan():
Because there is no way to read the signal exactly at the rising
edge,
using SVN head, this morning - arm920t - thumb single step fails to work.
However, arm920t - arm single step works.
and arm920t - thumb - break points work.
Sorry - no fix attached.
Level 3 log follows:
-Duane.
Debug: 39 112875 gdb_server.c:1954 gdb_input_inner(): received packet: 's'
Wijlaars, M.W. wrote:
Hello Duan,
I've been trying to debug the code with printf and even tried with GDB (Still
need to read The art of Debugginng). This is the first time I,ve used GDB
so I'm a bit at lost.
The code segfaults somewhere in the server.c file. I think the segfault
occurs
Marcel I have patch for openocd so it can write and erase the flash
memory on an ADuC 702x microcontroller.
Marcel The patch worked with an older version of openocd.
Steve [ I need it too ]
To Marcel,
If it ain't broke - why fix it? Why not use the old version?
Why change to the new version?
Øyvind Harboe wrote:
I don't know anything about the iMX27, but I've got an
iMX31 in my office where the JTAG chain now enumerates
properly.
FYI - the iMX27 has a 1.8V jtag pins, and wants/likes/needs RTCK.
Olimex JTAG Tiny (costs less) I think is 3.3V only.
simonqian [broke with iar tools]
duane [patches]
[several back and forths, ending with]
Simon - what is your status with OpenOCD?
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
I am trying to get an iMX27 to work, and need some help.
== Config File ==
$ cat openocd.cfg
telnet_port
gdb_port
source [find interface/signalyzer.cfg]
# I do not know if this is correct.
reset_config trst_and_srst
# I believe this is wrong, or missing an entry
jtag_device 4 0x01
SimonQian wrote:
simon -max-O-packet will not help.
For me, it is 100% required. Period.
Debug: 1418 58406 arm7_9_common.c:1190 arm7_9_debug_entry(): entered
debug state at PC 0x20329c
Debug: 1419 58406 target.c:799 target_call_event_callbacks(): target
event 4 (halted)
Debug: 1420 58406
There are 2 things in the attached patch that should help determine what
is going wrong.
(A) IAR has a problem with 'O' packets larger then 99 bytes
new GDB command to help work around that, see below.
(B) In the arm7_9 debug section, I added some LOG_DEBUG() messages
It seems there was little
the tail end of 'process reset' needs to flush the target callbacks.
The new patch assumes this was done in 'keep_alive()
W/ the keep alive fix this needs to be added.
-Duane.
Index: src/target/target.c
===
---
Nick Foster wrote:
Thanks to both of you for quick and effective responses! Everything
seems OK now on rev 986.
More importantly - thank you for confirming the problem is resolved.
Often I wonder if somebody figured it out - or if they gave up. You did
exactly what Eric Raymond's famous
Attached is the tcl reset patch.
Apply it to HEAD.
Unlike my previous patch, where the reset code was a separate file -
it is now integrated into startup.tcl.
The switch has been done. This defaults to the new TCL reset method.
You should - see no difference. If there is, please tell me.
Øyvind Harboe wrote:
I'm putting together some GCC/GDB binairies.
Comments/suggestions welcome:
Offering insight (gdb) instead might be better.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
] *
* *
+ * Copyright (C) 2008, Duane Ellis *
+ * [EMAIL PROTECTED] *
+ * *
* This program is free software; you can redistribute
I added you to command.c as well. I hope you don't mind.
Go right ahead.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
All -
Specifically:
Valentin Longchamp [iMX31?? issues]
Oyvind Harboe [general stuff]
Spen Oliver [str9 hackery]
Kees Jongenburger [ie: beagle board adding targets on the fly]
Nishanth Menon [ie: beagle board cortex-a8 etc]
I am now at the hear of the
Øyvind uh? What is this?
Øyvind What's arp?
duane [earlier]
FYI - in the work, the prefix arp_NAME stands for advanced reset
process.
Perhaps the arp_ prefix is dumb, and should be renamed.
I wanted to make this *CLEAR* that somebody should *NOT* be using the target0
halt
duane i am debugging some changes to the target_script command and
trying to restore some previous functionality that I think was broken
during the recent changes.
Oyvind Which specifically?
OLDThe old -(june time frame, before the big TCL switch)
OLD target.c - line 1530 supports the command
somebody STR912 now uses RCLK if available.
somebody Could i ask why? Because using rclk is slower.
somebody Is it?
somebody it has been on all the interfaces i have tested over the years.
somebody Even arm and segger mention this in their docs, if you have a
fast jtag tool
somebody in
Valentin Longchamp wrote:
I am testing with a jtagkey, but also expermimenting some problems
with svn revision from tonight. Reset halt does not seem to work for
me:
Valentin,
We had a series of emails about something with reset - and I am working
on some things dealing with event
Line 70 - file: jim-eventloop.c
extern int errno;
This is wrong, per the C standard.
-Duane.
Index: src/helper/jim-eventloop.c
===
--- src/helper/jim-eventloop.c (revision 959)
+++ src/helper/jim-eventloop.c (working copy)
Previous Patch:
nvp (name-value-pairs) to JIM
GetOpt - an option processing feature to Jim.
This Patch:
converts a number of 'simple string lookup tables' into NVP tables.
These NVP tables will be used by various commands coming in the next
patch.
Next Patch
(not included here)
Øyvind Harboe wrote:
Is it a good or bad idea to continue startup if validation of the jtag
chain fails?
Hmmm - do you mean OpenOCD should exit if the chain fails validation?
Of course with some type of big clear message why it is exiting.
-Duane.
All,
I've often seen these number messages:
JTAG device found: 0x2190101d (Manufacturer: 0x00e, Part: 0x1901,
Version: 0x2)
I think it would be helpful if they also included
MFG: 0x00e HUMANNAME, Part: 0x1901 HUMANNAME ...
For example - the urjtag package, in the data
Fix another warning..
-Duane.
Index: src/jtag/amt_jtagaccel.c
===
--- src/jtag/amt_jtagaccel.c(revision 947)
+++ src/jtag/amt_jtagaccel.c(working copy)
@@ -155,7 +155,7 @@
return ERROR_OK;
}
-void
Jason Gallicchio wrote: [lots of comments about tcl ish things]
First, remember this: OpenOCD uses JIM TCL - which is not Main Stream
Tcl/Tk.
JimTCL can be embedded in a rom target - something main stream Tcl/TK
cannot do.
This 'embedded feature' is some what helpful for some users of OpenOCD.
I noticed you are using the AT91SAM7 -
You might want to check out some of the things I wrote for the SAM7 also.
https://lists.berlios.de/pipermail/openocd-development/2008-July/002378.html
try this from GDB [from the above email]
Step 1:
(gdb) mon source [find
Sergey Lapin wrote
[boot strapping a lot of boards by hand]
One thing you might want to look at is the *OTHER* ways you can use the
FTDI 2232 chip (a very common jtag solution that openocd supports). One
of its other modes is an SPI programmer mode.
See this:
Øyvind Harboe wrote:
Hmmm... I tried to apply this patch, but it didn't work...
Did you create it in some new way?
Try #2 - this time using svn diff.
-Duane.
Index: configure.in
===
--- configure.in(revision 886)
+++
This patch:
1) enables numerous warnings in GCC [previously no warnings where enabled]
2) adds a disable-warnings option.
3) Cleans up the bulk of the warnings.
There is one that remains ... in jim.h...
Oyvind...
-Duane.
diff --exclude=.svn -Naur openocd16/configure.in
Øyvind Harboe wrote:
On Thu, Jul 31, 2008 at 1:06 PM, Dario Vecchio [EMAIL PROTECTED] wrote:
You could define a few step/breakpoint commands in tcl that has this
functionality. The existing functions would then be the low level
implementation
of hardware/software breakpoints.
Hello - I 've come across a few things that make no sense and seem wrong.
===
(a) example - top part of target.c' - target_init()
does this:
target-type-examined = 0;
Generally, the idea of type is a C version of a C++ method table.
(or what
Oyvind - I'm going to start making the changes we discussed
Valentin - this is FYI as you are some what following the previous thread.
So - I know what needs to be done - and Yes, I could use some help
testing these things. I guess Valentin volunteered to test some of this eh?
I'll let you
Øyvind Harboe wrote:
On Tue, Jul 22, 2008 at 5:23 AM, Duane Ellis [EMAIL PROTECTED] wrote:
Duane Ellis wrote:
Øyvind Harboe wrote:
Would you be interested in porting target_process_reset to Tcl?
Let me read through this code a bit and digest it.
I've
Putting my user hat on - I think we sort of went down the wrong path
with reset.
My reasoning and solution ideas follows.
-Duane.
Background:
Openocd is part of a debugger - it is not a board or program that runs
freely.
When something is under the control of a debugger - in
Øyvind Harboe wrote:
Committed.
But: the cortex_m3.tcl is missing. Committed the others.
Please submit a patch against trunk. Doesn't your tool
allow creating patches that adds/deletes/moves files?
OOPS -- Sorry. I also found a typo in another file.
I've been using svn diff - it does not
In my environment:
Linux machine -development host. Located in my basement.
Desktop: WinXP with X11 remote session to Linux machine.
OpenOCD runs on the WinXP machine.
DDD 'code-sourcery-gdb' runs on linux machine in basement.
The display is 'remote' to my desktop in my 2nd
Fix some breakage.
(1) The renaming in C ofmem2array - to openocd_mem2array broke
things [scripts did not get renamed]
(2) Other places - the prefix was inconsistant -- some places openocd_
some ocd_
This patch normalizes all to ocd_
-Duane.
Index: src/helper/startup.tcl
Improve error message in Jim when sourcing a file fails.
Previously it did not tell you the CWD Jim was using as its reference point.
(Helpful when script filenames are a relative path)
-Duane.
Index: src/helper/jim.c
===
---
As before - I created some tcl script commands for the atmel at91 parts.
This is likewise for the stm32 parts.
It is limited - and is a starting point for others to make use of.
-Duane.
Idea is as follows (just like at91)
In your openocd.cfg file, add this line:
source [find
Short version is this:
You *MUST* be able to change the JTAG clock frequency - *at*least* by
hand to any value - at any time using a command.
The Long version - with explanation follows
Pieter The AT91SAM9260's JTAG speed must always be 6 times lower than
its clock speed.
The true
Spen wrote:
... slider switches
Yes, they are all in the flash mode now.
No difference.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
duane Hmm, something does not work with the cortexm3 breakpoints.
spen The problem is caused by the target_resume function, try svn head now
Much better.
-Duane.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
201 - 300 of 315 matches
Mail list logo
