On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote:
> > Oyvind sorry, I just can't find it ... could you tell me where it is
> > please ?
>
> Start here:
>
> https://lists.berlios.de/pipermail/openocd-development/2010-September/01648
> 2.html
Hey,
I went through all of this stuff tonight ..
On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones wrote:
> Hi all,
>
> I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built
> about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare
> Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6,
> an
Hi Chris,
I'm not an expert, nor a typical poster on this list, but have you properly
configured the DBGMCU_CR register to allow debugging support while the STM32
is in STOP mode?
Best,
Kyle
On Fri, Oct 29, 2010 at 2:58 PM, Chris Jones wrote:
> Hi all,
>
> I'm using OpenOCD (version 0.4.0, do
Hi all,
I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built
about half an hour ago) on Debian Lenny (5.0, stable) running under
VMWare Fusion on an x86 Mac Pro. The microcontroller I'm using is an
STM32F103C6T6, and the JTAG dongle is an Amontec JTAGKey. By and large
it wo
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
Hi Bill,
I recently tried OpenOCD and encountered the same problem. The cause seemed
a relatively recent checkin that was attempting to add swj support. I've
been bad though and haven't made a patch or filed a bug report. My quick
fix was to comment out the two lines in stellaris.cfg that were
billium wrote:
> I had a problem with lm3s6965:
>
> Open On-Chip Debugger 0.5.0-dev-00565-g4617cd0 (2010-10-28-19:55)
> Info : JTAG tap: lm3s6965.cpu tap/device found: 0x00ff (mfg: 0x07f, part:
> 0x, ver: 0x0)
> Warn : JTAG tap: lm3s6965.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part:
> 0x
I had a problem with lm3s6965:
Open On-Chip Debugger 0.5.0-dev-00565-g4617cd0 (2010-10-28-19:55)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
"Peter Stuge" napisał(a):
> Unless there is a way to tell devices apart.
Usually there is (; Sometimes some more logic is required, but generally that
is possible (JTAG ID, special registers with ID, flash sizes, etc.)
> > BTW I do not prefer single file for whole family,
>
> Why not? No
Xiaofan Chen wrote:
> > A GUI utility to do usual things would be even nicer - specify
> > interface/chip, press "connect", select image file, press "flash"
> > and that's it!
>
> That would be nice. Somewhat along the line of H-Jtag would be nice.
I like this idea as well. Not so much for my own
oyvind.har...@zylin.com napisał(a):
> I think that OpenOCD should stay away from GUI's and focus on
> the core functionality. Just like GDB does. GDB isn't a GUI,
> but it *supports* GUIs.
Sure, I also think that OpenOCD does not need an embedded GUI, but I hope that
someday someone will make a
"Peter Stuge" napisał(a):
> You must have missed the patches.
I don't think so. SWD is being talked about for ~2 years, in the meantime
SWD-only chips appeared on the market (LPC1xxx, LPC13xx, etc.), commercial and
free toolchains support it already, OpenOCD is (IMHO) not even close... Sure,
On Fri, Oct 29, 2010 at 10:24 AM, Peter Stuge wrote:
> freddie_cho...@op.pl wrote:
>> I think making OpenOCD more user-friendly and having SWD support
>> would be a major brakthrough for it, bot I think nothing is going
>> on in those areas...
>
> You must have missed the patches.
>
> I also think
2010/10/29 :
> > A GUI utility to generate the config file would be nice.
>
> A GUI utility to do usual things would be even nicer - specify
> interface/chip, press "connect", select image file, press "flash"
> and that's it!
That would be nice. Somewhat along the line of H-Jtag
would be nice.
h
freddie_cho...@op.pl wrote:
> I think making OpenOCD more user-friendly and having SWD support
> would be a major brakthrough for it, bot I think nothing is going
> on in those areas...
You must have missed the patches.
I also think user friendliness and SWD are good improvements. If you
can help
Øyvind Harboe wrote:
> >> So if anything, you would add a parameter for dap_base.
> >
> > Could you point me in a direction please?
>
> This should be picked up automatically, so this is the wrong direction.
>
> If you type "dap info 0", I believe it prints out the debug base,
> so the code is ev
Marek Vasut wrote:
> > add a parameter for dap_base.
>
> That's what I wanted to do, but I'm still starting to get familiar
> with OpenOCD again. Could you point me in a direction please?
Um, well, don't you just do the same thing as you did for -variant,
except use strtoul() in the C code?
//
freddie_cho...@op.pl wrote:
> > I was considering this too. I strongly prefer a single file for the
> > entire family if possible, but it should not cost very much, if any,
> > performance.
>
> But in this situation single file costs performance,
Unless there is a way to tell devices apart.
"Xiaofan Chen" napisał(a):
> I understand your concern. However, if you have a good wiki
> and documentations (say put in the comment in the starting
> of the config file), then it would not be too bad. Just ask
> the user to RTM/RTFM. ;-)
That's not the case of telling somebody to do RTFM,
On Fri, Oct 29, 2010 at 2:43 PM, Peter Stuge wrote:
> The ideal would be for openocd to identify the device. I guess IDCODE
> is not good enough to tell two devices with the same core apart, so
> we really have to rely on user input for it. :\
>
Ah, good idea. I think a new parameter is good to
2010/10/29 :
> "Xiaofan Chen" napisał(a):
> > Yet another solution is to have a generic cfg file with minimum
> > 4KB of SRAM but allow user to overwrite the generic config
> > file with bigger working area for better performance.
> >
> > Is this possible?
>
> Of course it is possible, but h
> Oyvind sorry, I just can't find it ... could you tell me where it is please ?
Start here:
https://lists.berlios.de/pipermail/openocd-development/2010-September/016482.html
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51 63 25 00
http://www.zylin.com/zy1000.html
ARM7 ARM
On Fri, Oct 29, 2010 at 9:33 AM, Marek Vasut wrote:
> On Friday 29 October 2010 07:43:18 Peter Stuge wrote:
>> Marek Vasut wrote:
>> > In this patch, I introduce the use of -variant parameter, so I can
>> > adjust the debug_base accordingly.
>>
>> This seems completely wrong to me. I think this lo
On Friday 29 October 2010 08:18:46 Marek Vasut wrote:
> > On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut
> >
> > wrote:
> > > > On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut
> > > >
> > > > wrote:
> > > > > > Shouldn't this be automatically detected?
> > > > >
> > > > > yes it should ... i'll sen
On Friday 29 October 2010 07:43:18 Peter Stuge wrote:
> Marek Vasut wrote:
> > In this patch, I introduce the use of -variant parameter, so I can
> > adjust the debug_base accordingly.
>
> This seems completely wrong to me. I think this logic should just
> stay in Tcl. So if anything, you would ad
Going twice...
I'll be merging this beginning of next week not to ruin
anyones(especially mine! :-) weekend if there is any
fallout.
It would mainly be with documenting and
build procedures and laying out some bread-crumbs
to follow.
--
Øyvind Harboe
US toll free 1-866-980-3434 / International
"Xiaofan Chen" napisał(a):
> Yet another solution is to have a generic cfg file with minimum
> 4KB of SRAM but allow user to overwrite the generic config
> file with bigger working area for better performance.
>
> Is this possible?
Of course it is possible, but how many users will know tha
27 matches
Mail list logo
