--- On Wed, 1/12/11, simon qian wrote:
From: simon qian
Subject: [Openocd-development] include interface configuration first or target
configuration first?
ISTR concluding interface first, since not all
targets work with all debug adapter interfaces.
E.g. a target only supporting JTAG or S
--- On Tue, 1/11/11, Peter Stuge wrote:
> From: Peter Stuge
> Subject: Re: [Openocd-development] SWD progress
> To: openocd-development@lists.berlios.de
> Date: Tuesday, January 11, 2011, 11:06 PM
> simon qian wrote:
> > SWD in Versaloon is based on operation.
> > For example: A read operation
--- On Tue, 1/11/11, Tomek CEDRO wrote:
> others). David provided his sources for SWD some time ago,
I'll disagree a bit ... I've provided a
bunch of mid-level infrastructure, but nothing
I'd yet call (usable-as) SWD, since no driver is all there. That's on the way
though.
(I don't want ex
--- On Tue, 1/11/11, simon qian wrote:
I'm back for SWD
welcome back!
Is the SWD transport usable now in OpenOCD?
Not yet; There's only infrastructure, not an
entire transport (going down to driver level).
I have two patches in the works: (a) init,
e..g. call SWD driver init to set up WC
--- On Fri, 12/31/10, Antonio Borneo wrote:
> Table of NAND devices reports
> operating voltage.
> Replace comma with proper decimal dot.
A more accurate patch comment would be that you
are changing the localization for those numbers.
In some parts of the world, dot/period is the
convention. I
via Google search, I found the following, which, in conjunction with the
Cortex-A9 reference manuals from ARM, may be of interest to folk looking
at OMAP4 and other recent TI chips for OpenOCD; it looked to answer some
of the questions I've heard on this list.
http://processors.wiki.ti.com/index.p
Also, as promised some time back I'll soon
commit my second SWD "framework" patch. The
build issues with mainline OpenOCD have now been
resolved; framework patch got updated; and it passes
sanity testing. BUT ... SWD won't yet be fully
functional in OpenOCD.
The commit will mean: add some SWD d
--- On Thu, 12/23/10, Tomek CEDRO wrote:
> http://files.tomek.cedro.info/electronics/arm/cortex/libswd/
I took a quick look. Two comments:
Looks at first glance like it might help
write some types of bit-level SWD driver
(not ones that use higher level commands, as needed to support for ex
I can't find the original message with
this $SUBJECT to reply to it ... but wanted
to point out that it's nonsense.
Beagles have single OMAP3 based chips, and
thus have Cortex-A8 cores.
If you want a Cortex-A9 board, look at the
PandaBoard instead. Right now they're hard
to find; supply limited,
> + it has to do with whether you want to use the
> installed Jim Tcl or not.
Or more typically: if there even *is* one...
More likely to be a "real" Tcl installed, IME.
Maybe someone with time and knowlege can come
up with a wrapper that makes Real Tcl look and
behave like Jim. ;)
_
--- On Sun, 12/19/10, Øyvind Harboe wrote:
missed.
>
> I'm thinking that bootstrap could be split in two:
>
> - a script that does what it does today and that can be
> invoked
> directly.
Two bootstraps might make sense. That one
might be mostly for GIT-less environments,
as from a source/d
Example: against a fresh clone of mainline.
I think it ought to support "configure"next ... but instead it seems to
require more, and
thus is needlessly error prone... Folk won't often be
reading script output except to see and fix well-flagged errors, so
the need for two submodule commands is e
--- On Sun, 12/19/10, Øyvind Harboe wrote:
> So you don't think there is a disadvantage to
using variables
> to pass information around?
I never said that. Are you saying that one
goal is reducing usage of globals? That's
generally a good thing ... but since you had
stipulated that the sing
--- On Sun, 12/19/10, Øyvind Harboe wrote:
>
> > A good simplification would be to remove every
> > non-BIG endianness setting.
> The big/little endian issue is orthogonal to how we
> organize the config files.
But not to $SUBJECT of this specific thread.
>
> What do you think about th
> Øyvind Harboe wrote:
> > A board script should export a single procedure
> without arguments
> > with a name that's fixed by convention.
Is there an advantage to that approach? After
all, a script file *is* essentially a single
procedure etc (nameless, but no never mind).
_
--- On Sun, 12/19/10, Øyvind Harboe wrote:
> -if { [info exists ENDIAN] } {
> - set _ENDIAN $ENDIAN
> -} else {
> - set _ENDIAN little
A good simplification would be to remove every
non-BIG endianness setting. When not
specified, the OpenOCD default is "little".
Including "little"
--- On Wed, 12/8/10, Gabi Voiculescu wrote:
> From: Gabi Voiculescu
> Subject: [Openocd-development] need help flashing OMAP3530 on beagle rev C3
Don't use OpenOCD; it doesn't have the NAND
driver it would need ... or is it just hiding
from me for now? If you've got a working
version of U-Bo
you mentioned using an RTOS. Stepping on Cortex-M
works poorly with a common OS feature: Use of the
WFI (or WFE) instruction stops the core so that you
can't get at it using JTAG.(It saves power, but
in a way that complicates debugging.)
My baby Cortex-M RTOS has a build/coonfig option
for
--- On Mon, 12/6/10, Karl Kurbjun wrote:
> All device vendors should provide BSDL files for their devices
Yes, and they're not necessarily easy to find.
which
> specify the maximum TCK speed the device can support.
On appropriately designed and manufactured
boards, only. So that's an
--- On Mon, 12/6/10, Laurent Gauch wrote:
> > I don't subscribe to the idea that there is a safe,
> correct and robust
> > default setting for JTAG clock,
The only thing that'd prevent a given board from
having such a (board-specific) setting is using
it with a debug adapter that doesn't su
--- On Sun, 12/5/10, Freddie Chopin wrote:
> So how about this idea of removing
> useless and wrong occurences of srst_pulls_trst from lpc config files?
Which ones are useless? Which are wrong? And
for the latter , why haven't we seen specific bug reports, followed by trivial
patches?
The
> > --- On Sun, 12/5/10, Øyvind Harboe
> wrote:
> >
> >> Does anyone have any objections to
> >> getting rid of the
> >> concept of a default JTAG clock rate?
> >
> > NO. But let's see a proposed patch ... :)
>
> Could you clarify a bit what you are against?
I'll know it if I see it. :)
My co
--- On Sun, 12/5/10, Øyvind Harboe wrote:
> Does anyone have any objections to
> getting rid of the
> concept of a default JTAG clock rate?
NO. But let's see a proposed patch ... :)
I recall some discussions a while back about
how JTAGKEY2 was broken because its driver was
embedding a defaul
--- On Fri, 12/3/10, Austin, Alex wrote:
> I imagine the problem is voltage,
> actually. The OMAP3530 and other similar devices run their
> JTAG ports at 1.8V,
True, and important. Thought I'm not sure
quite what you mean by "Similar". Don't
the Sitara chips run at 3V3 not 1V8? And
I though
--- On Fri, 12/3/10, Spencer Oliver wrote:
> Date: Friday, December 3, 2010, 2:34 PM
> On 03/12/2010 17:24, David Brownell
> wrote:
> >
> >
> > --- On Fri, 12/3/10, Spencer Oliver
> wrote:
> Sorry i am slightly confused this patch as such has nothing to do
--- On Fri, 12/3/10, Spencer Oliver wrote:
> > 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 -
I've lost track of the discussion her
--- On Wed, 12/1/10, Freddie Chopin wrote:
> This is also an important issue (; Rowley has done a
> "converter" for Amontec JTAGkey,
THe converter is rather generic, and some OpenOCD
folk have its schematic. Rowley's driver might
not work except with JTAGkey ... but I'd
see no reason a "shim"
On 30 Nov 2010 08:46, wrote:
>...
>
> Have you synchronized your work with that of Tomek Cedro?
It should go the other way around. The only part of my work that's not yet
been public is a driver that first needs test-time; OpenOCD integration has
been on-going. Nobody has bothered asking any
--- On Mon, 11/29/10, simon qian wrote:
How is going on SWD support?
No changes since my last update; I was
getting ready to merge the framework code when
the merge of the new Jim code made everything
break for me. I've not yet had time to go back
and unbreak things.
Plans are still: (i) me
FWIW I've used an Olimex JTAG-Tiny with a level shifter from Spectrum to
handle the 20pin-to-14pin issues.
On Thu, 2010-11-25 at 08:28 -0600, Nishanth Menon wrote:
> > ~50$ or
> > so.. or is openOCD more of a
> > would-be-useful-debugging-kernel-with-infinite-time thingy?
>
> Show my an example of any _normal_ JTAG interface that does
> not have srst?
Depends entirely on what you mean by "normal",
doesn't it? All I can say is that I've come across non-prototype boards that
don't rely
on that signal, and thus don't provide JTAG
support for it. That is, boards
--- On Fri, 11/12/10, Peter Stuge wrote:
> I'm not thrilled about having this information local in the
> spearsmi
Like generic SPI and SPI-flash layers. The flash
support shouldn't be SPEAr-specific in the least.
___
Openocd-development mailing lis
--- On Fri, 11/12/10, Freddie Chopin wrote:
> it's hard to imagine a chip that has no srst,
As for boards or JTAG adapters without nSRST,
no imagination is required; I have production
boards of both flavors.
> that option can be removed
Shouldn't be, though; that'd be very unwise.
- Dave
--- On Thu, 11/11/10, Øyvind Harboe wrote:
> What output do you get when running bootstrap?
This time I noticed some stuff ... but that seems
wrong. Bootstrap should bootstrap, not leave the
job incomplete and in need of repairs.
>
> It should print the instructions on how to build and ins
After bootstrap and configure (per instructions), I get
build failures on Linux with an
all but pure clone of mainline. (Quilt and git report only
a patch to the git ignore file, not to any code.)
Same config I've used on this machine most of the last year.
make all-recursive
make[1]: Enteri
--- On Thu, 11/11/10, Andreas Fritiofson wrote:
> It's not an assumption, it's in the manual. Do you have an example of
> a microcontroller which doesn't reset the bulk of the peripherals on a NRST
> or equivalent?
Not handy, no; it surprised me too. ISTR there
was a register controlling th
> >>> Today I've noticed that resetting the chip
> with OpenOCD does NOT reset
> >>> peripheals (the chip is STM32F103RBT8), which
> IMO is not very good...
Not all SoCs reset peripherals like that; don't
assume they do. Likewise, not all boards.
- Dave
__
--- On Tue, 11/9/10, 韦东山 wrote:
> From: 韦东山
> Yes, it can't enable the Cortex core. I delete this line in
> the cofigration file:
> " jtag configure $_CHIPNAME.jrc -event setup "jtag
> tapenable $_CHIPNAME.dap" "
>
> and run "jtag tapenable omap3530.dap" in the telnet
> windows, the output i
> tool to debug omap3530, the config file is
> ti_beagleboard.cfg.
Known to work with OMAP-3430. I don't know
about the 3530; it's at least a bit different.
I guess your Beagle has that newer OMAP...
> It can find the ICEPick, but can't find the arm
> core.
It won't just "find" the Cortex cor
On Fri, 2010-11-05 at 14:57 -0700, Kevin Hester wrote:
>
> proc init_stellaris {} { init poll flash probe 0 }
>
> init_stellaris
Not that I use Stellaris with GDB lately, but that stuff should be
superfluous, since the normal startup should activate/probe flash.
It certainly d
> > Then I question the gain of this function.
>
> My thoughts too.
>
> Perhaps there should be a configuration option?
> --enable-dev-creature-comforts.
There's a runtime option that suffices, and is
set up in my test/dev scripts. "-s tcl" or
similar, if I recall correctly.
- Dave
_
--- On Tue, 11/2/10, Øyvind Harboe wrote:
>
> I don't know what the answer is long term. I would, like
> you,
> like to hear thoughts from others on this.
There's a bug filed about us not reporting the
memory maps correctly, with specific reference
to RAM/SRAM regions. Fixing that would help
I think caring about the "variant" should strongly
be avoided. Use the ROM table by default. Only in
the case of a broken ROM table should we (a) emit
a message, then (b) work around the brokenness.
Such working-around might care about variant, if wecan't come up with a simple
heuristic fix.
-
> #define swjdp_memoryap 0
> #define swjdp_debugap 1
For Cortex-A8 it's likely not SWJ-DP but
instead JTAG-DP ... regardless it's best
not to try exposing irrelevant details
like that in naming conventions here...
>
> +static const char *variant = NULL;
"variant" is never changed but ...
> .
I had a problem with lm3s6965:
...
srst_only separate srst_gates_jtag srst_open_drain
That looks wrong ... I don't recall that
Stellaris parts wanted gating or open drain.
And for that matter, the generic stellaris.cfg
worked for me quite recently, so I suspect some
issue with your customized
On Mon, 2010-10-11 at 03:23 +0200, Tomek CEDRO wrote:
> Hello David, nice to hear from you! :-)
>
> I am working on it - preferably FT2232 (KT-LINK) first, then RLink
> (Stm32Primer2).. but RLink can be more accessible on the STM32Primer2
> boards.. and also needs some reverse engineering on the
From: David Brownell
Subject: initial SWD transport (SWD infrastructure #2)
This piggy backs on JTAG so it's not yet pretty, but that
seems unavoidable so far given today's OpenOCD internals. I'd
rather see JTAG and SWD be fully separate.
I'm posting this to share infor
If you've paid attention, you have seen this patch before (or a very
slightly earlier version). I expect to commit it soonish on grounds
that it'll be needed, and seems innocuous/safe, and will move us just
a bit closer to working SWD ... :)
From: David Brownell
Subject: swj-d
The original accidentally went just to Zach; so here it goes to
all openocd, as intended.
On Sun, 2010-09-26 at 20:44 -0700, Zach Welch wrote:
>
> BTW, how is your progress coming on SWD? Having just dived into all of
> the relevant ARM specifications, I can see that you've done a lot of
> work
--- On Thu, 9/30/10, Gene Smith wrote:
> From: Gene Smith
> Subject: Re: [Openocd-development] cortex-r4 core
> To: openocd-development@lists.berlios.de
> Date: Thursday, September 30, 2010, 12:42 PM
> Laurent Gauch wrote:
> >
> > Built-in XDS100v2
> >
>
> Not sure if this is good "!!!
> Presently, I would like to hear about the perceived status > of Cortex-A8,
It gets through OMAP3 bringup. The ROM table
scanning embeds various assumptions; see the
comments in the ARM ADI_V5.c file. I'm not sure
whether it's good to assume DAP 0 is used, as one
of the examples, of which MEM-
> >> If the section addresses does not match the actual
> memory layout of
> >> the target, there's nothing gdb can do about it.
> >
> > I disagree; gdb can certainly discover this has, and must have, the offset.
> > It's
GDB runs by the memory map that OpenOCD feeds it
during startup. That
Good. Lets me remove a similar patch from my queue ... :)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
> > All these zeroes suggest either a TAP which
> > legitimately has no IDCODE instruction support
> > (and thus looks like IDCODE == 0) ...
> >
> > ... OR else hardware problems somewhere in the
> > JTAG chain, possibly in some other TAP.
> >
>
> Hello David,
> I am not so sure about this. Still
jtag_examine_chain_display()
> 74376: JTAG
> tap: mico_2.cpu tap/device found: 0x01273043 (mfg: 0x021,
> part:
> 0x1273, ver: 0x0)
> Info : 218 293 core.c:949 jtag_examine_chain_display()
> 74032: JTAG
> tap: mico_3.cpu tap/device found: 0x01273043 (mfg: 0x021,
> part:
> 0x1273, ver: 0x0)
> Info :
--- On Sun, 8/22/10, Prashant Badgujar wrote:
I would like to know, what are the JTAG based debug hardware that are
supported under openocd?
The User's Guide is on-line, and has that information. Check there for
that and othere basic information about OpenOCD.
___
--- On Mon, 8/16/10, Michel Catudal wrote:
> > Irrelevant. AVR32 uses the Nexus protocols,
> > layered on top of JTAG. Those are public and
> > need no licensing.
> >
> >
>
> For devices where you need most of the pins Nexus can't be
> used.
Not wholly true. Trace needs lots of pins,
t is in use. STM32 being the only one
with much complication (since it's got a separate JTAG TAP for boundary scan,
which really ought to
get declared -- iff JTAG is in use not SWD.
From: David Brownell
Subject: swj-dp.tcl (SWD infrastructure #1)
Provide new helper proc that can set up either
led, that branch won't execute; so outside
of the stupid bug, this logic shouldn't yet change much.
=
From: David Brownell
Subject: swj-dp.tcl
Provide new helper proc that can set up either an SWD or JTAG DAP
based on the transport which is in use -- mostly for SWJ-
> > I have no license to use JTAGICE mkII protocol.
Irrelevant. AVR32 uses the Nexus protocols,
layered on top of JTAG. Those are public and
need no licensing.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.b
--- On Sat, 8/14/10, Oleksandr Tymoshenko wrote:
> Here is initial version of AVR32
> support for openocd:
Cool! would you happen to know the latest
story on mainlining binutils, GCC, and GDB support
for that arch? Last I heard, Atmel's code was
public but not (for some silly-ass reasons tha
> > I'd think serial numbers would suffice, and
> > be much more usable/stable.
> >
> I think a USB device is not required to have
> a serial number,
But FTDI devices *DO* ... all I've seen. In fact
the current FT232 usb-to-serial parts are all
manufactured by FTDI with unique serials; it's
I's think serial numbers would suffice, and
be much more usable/stable.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
One way you can tell this is very wrong is that it
references JTAG-specific registers APACC/DPACC ...
those concepts don't even exist with SWD.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/li
I don't recall problems in this space... quite
the opposite (arm9).
If "reset run" leaves the target in reset or halt
instead of running, that's a bug to fix
by ensuring the target is running.
- Dave
___
Openocd-development mailing list
Openocd-deve
--- On Wed, 8/4/10, Øyvind Harboe wrote:
> I have never used it.
Not a fair reason to get rid of any command.
Just like
> protection check, it can't base itself on
> cached information, so perhaps it is broken to the point
> where
> it should be removed rather than fixed?
If it uses broken
My question is about the "flash erase_check"
command, is that still required/valid for same reason?
Without it, you can't tell what blocks are erased, vs
holding data/code already.
___
Openocd-development mailing list
Openocd-development@lists.berlios.
--- On Tue, 8/3/10, Peter Stuge wrote:
> I don't think there's much of a JTAG engine on the FT2232 - I think
> it's just bitbanged, which would also explain the massive
> debug
> output.
It's not bitbanged; there's decent SPI/JTAG engine
called MPSSE. Read the docs.
A bit awkward to program,
--- On Mon, 8/2/10, Øyvind Harboe wrote:
> From: Øyvind Harboe
> Subject: Re: [Openocd-development] lpc1768 low clock rate
> To: "David Brownell"
> Cc: "Freddie Chopin" ,
> openocd-development@lists.berlios.de
> Date: Monday, August 2, 2010, 2:0
> But why as low as 100kHz?
Because no reset-init method is kicking
in the xtal oscillator and PLL, so the chip
is clocked almost as slow as it'll go.
You want faster? Write a real reset-init
method that clocks the chip faster ... at least
until app code kicks in and overrides.
- Dave
__
> Does anyone have any idea why the
> lpc1768 requires
> such a low clock rate?
>
> "reset run" seems to require as low as 100kHz Could
> this
> be due to the app I'm running is messing with the clock?
Probably. The chip can run at 100 MHz ISTR,
but if it's running at a slower rate, JTAG wil
SWD support is coming soon?
Plans unchanged; yes. Next patch will be
transport glue for SWD ... then it'll be time to
update drivers to support it, and tweak things
to fill in the holes.
I'll prepare the patch for versaloon.
Good, that'll help.
- Dave
Quick update on $SUBJECT: it's come up OK for me
recently, possibly resetting or halting the
stellaris target was a key step.
I could see the TPIU, ITM, and DWT instead of
spurious NVICs. And on LPC1768, the ETM also.
Puzzling, but now less worrisome...
- Dave
__
> I think the best approach would be if you could
> provide patches to openocd/master for
> improvements for this architecture.
Yes, I think it's recognized that the current code
has weaknesses. Blame it on the chip vendor never
having helped merge their support upstream ...
Aren't there potent
--- On Fri, 7/16/10, Freddie Chopin wrote:
\\\
> 1. There are 3 pins required for SWD right? SWDIO, SWCLK and reset?
And power (2 pins) ...
> a. SWCLK is TCK?
> b. SWDIO is TMS?
SWDI and SWDO == SWDIO: bidirectional.
TMS is unidirectional.
> c. reset is nSRST?
> 2. Does "demultiplexed" SWDIO
> > thanks for your reply. Any chance you still
> have that patch around somewhere?
>
> Yes, but not accessible for the next couple
> months (wrong coast)...
Or maybe not. Here it is -- don't know if it
still applies or works though.
- DaveFrom: David Brownell
Subject
--- On Thu, 7/15/10, Alex Hornung wrote:
> Hi David,
>
> thanks for your reply. Any chance you still have that patch around somewhere?
Yes, but not accessible for the next couple
months (wrong coast)...
Or maybe you can point me into the right
> direction on where
> to look.
Look at the
--- On Wed, 7/14/10, Alex Hornung wrote:
> It seems that the first jtag scan works
> successfully, but subsequent
> scans fail miserably. The 'reset' command works
> (the device *is* reset)
> but it throws an error:
>
> JTAG scan chain interrogation failed: all ones.
> Check JTAG interface, t
--- On Mon, 7/12/10, Spencer Oliver wrote:
>
> The newer versions of the luminary boards have
> replaced the cpld with
> logic aswell, have a look at the new 811 user guide.
No; the 811 was always discrete. Not all boards
used CPLDs, just a few. I don't think they've
ever changed from CPLD
--- On Mon, 7/12/10, Spencer Oliver wrote:
>
> Just for info rowley in the uk produce a swd
> adapter for ftdi based dongles.
> I have one here and it works very well with their software.
Maybe it could start working with ours at
some point too ... ;)
>
> http://sites.fastspring.com/rowley/p
> From STM32 & ZY1000 using current
> master branch:
Looks OK to me. Maybe a bit thinner than
the other ROM tables I'm used to seeing,
but that could just be STM32 vs fancier
chips (OMAP3, LPC1768, etc).
Thanks -- this suggests maybe I was on the
right track to think of layout bug in luminary.
> Is there any schematics available for
> this adapter?
Yes, lm3s3748-ek. See the user's guide. This
is one that uses a small CPLD external to the
ft2232 chip. So the schematics include just a
bit of tracing through CPLD logic...
> I've placed an order for one to have a look
Somehow I
> > > For the near future, I think the LM3S811-EK is
> > > likely to be that hardware.
> >
> > Is the code that it would run available?
Not yet (for SWD with OpenOCD) ... only for its
JTAG mode (part of standard OpenOCD).
> --8<-- LM3S811 Evaluation Board User's Manual
> An FT2232 device from
> > Can some of you help sort this out?
>
> I'll get an LPC1343 in a few days,
I've got to cut my LPCXpresso-1343 in half
to get rid of the proprietary HW that only
works with CodeRed's MS-Windows tool... ;)
But rest assured, that's on my list of stuff
that gets SWD testing and config "early".
The Cortex parts (M3, A8, etc) all have ROM tables listing
resources exported to debuggers, which are displayed in
OpenOCD using the "dap info" command. I've seen this
work well with Luminary (LM3s3748), NXP (LPC1768),
and OMAP3 parts in the past.
However, I recently observed two Cortex-M3 parts
I'm guessing that if I wanted to try to contribute to OpenOCD to add this
support, there would be a very steep learning curve.
Maybe. The TCL bits, plus whatever display technique
is used -- ideally, through the web server. The TCL stuff
is easy and you'll want to know that if you work much a
--- On Sun, 7/4/10, Stacey Sheldon wrote:
> Commit 93f2afa45f4c dropped the
> sentinel off the end
> of the command_registrants[] array. The loop
> immediately
> following the initialization will walk right off the end.
Dropping that was an accident, but it's odd that
my testing didn't trigge
--- On Sun, 7/4/10, Peter Stuge wrote:
>
>
> Hmm. Are you sure that all NXP M3 do it? Which one did you look at?
Maybe not, but at least the LPC1768 can, and ISTR
others too. You're right that the LPC1343 has yet
another option for bootloading.
> interested
> in anything else you know a
I committed the "transport" framework patch; you've
seen it on the list before, the main difference ince
the last post was adding user's guide docs.
(This has been ready for some time, and I got tired of just carrying it
privately. It's groundwork, and shouldn't affect anyone's work; but if it
> I'll let this cool off for a few days
> and then I'll commit it.
Great; I wish I could do that but my current
patches-from-email situation is malfunctioning.
> It has gotten positive testing feedback so far,
I'd like clarification on that: there were two
patches. This #2/2 was more invasi
These read OK, I thought, but I'm not in a
position right now to review (in detail) or
verify either patch.
Could someone with an FTDI-based adapter
please try these out and verify them? Then
maybe have a committer commit them, if they
ideed check out?
The first one looked pretty obvious (cleani
--- On Wed, 6/23/10, Øyvind Harboe wrote:
> I made a fleeting vain attempt
> setting up the vector
> catch register to halt upon reset.
VCR is the right solution. I've seen it
work on every ARM chip I've tried it on.
There are some TI chips that use magic
EMU0/EMU1 settings to achieve the sa
--- On Mon, 6/21/10, Øyvind Harboe wrote:
> From: Øyvind Harboe
> Subject: Re: [Openocd-development] TI AM3517 status
> Looks like I'm talking
> to the CPU at least as it seems to be able to figure out
> that
> the CPU has 6 breakpoints and 2 watchpoints, which sounds about right I
> suppose
> Has anyone done any work on that chip?
Don't have one, but ISTR it's more or less
an OMAP3 flavor aimed at indistrial apps.
SO treat it as an OMAP3 at first.
(Distinct from a DaVinci with Cortex-A8...)
Suggest you look at how the linux-OMAP tree
handles it
> I've got the AM3517 EVM eval
To support that chip for debugging,
we'd need specs for more of its
JTAG operations ... Atmel has not
made them public. (yet).
Meanwhile, I understand that you
can use OpenOCD to program flash
on such AVR8 chips... but not debug.
(Atmel did document those operations.)
__
Thanks, I'll have a look.
Just so you know, the plan I previously posted is
still progressing: Patches merged will be roughly:
- "transport" framework ... basically ready to merge, but I'm on
the road now and without some testing code I'm used to .. and
recreating it with CMSIS is curiously
--- On Tue, 6/1/10, Vianney Pouget wrote:
> In the function bitbang_execute_queue(), I don't understand
> the difference
> between the :
> - case JTAG_STATEMOVE and
STATEMOVE -- move to a specified state,
pick some path through the JTAG state machine
(and issue its TMS transitions).
> - case JT
> > I tried to add support to LPC11XX in vsprog.
> > LPC11XX is CortexM0 from NXP.
We want "OpenOCD" support, not "vsprog" support,
for such things ... :)
> Aha! I think that's exciting! I am most interested in
> LPC13xx, but I
> assume there may be some things in common.
Yes. 13xx is Cortex-M3
--- On Sun, 5/23/10, Jon Povey wrote:
> I've been trying to get a trace out
> of my DM355 with ETM v1.3 and ETB; I've been reading ARM
> IHI0014O and the OOCD source code but struggling to get a
> trace out.
RIght. I don't think that code can ever have worked;
it's not worked when I tried it
> But what about the actual issue of the incompatible syntax?
> The label is unimportant.
Tough to change that syntax now. I wouldn't have made that change
in that way perhaps, but it's done at this point, fix all configs.
___
Openocd-development
1 - 100 of 2101 matches
Mail list logo
