On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote:
Shouldn't this be automatically detected?
yes it should ... i'll send a patch on top of this one once I
figure out how to do it. Is that good enough approach for you?
Or shall we put these on hold until then?
I
On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut marek.vasut.n...@gmail.com wrote:
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut
marek.vasut.n...@gmail.com wrote:
Shouldn't this be automatically detected?
yes it should ... i'll send a patch on top of this one once I
figure out how to do
On Fri, Oct 29, 2010 at 3:41 AM, Freddie Chopin freddie_cho...@op.pl wrote:
Of course another solution would be to create a general cfg file and small
dedicated cfg files for every STM32 device available (currently 89) - these
would use (include) the general cfg. The structure of the target
Xiaofan Chen wrote:
create a general cfg file and small dedicated cfg files for every
STM32 device available
Yet another solution is to have a generic cfg file with minimum 4KB of SRAM
I think this was the idea.
but allow user to overwrite the generic config file with bigger working
Peter Stuge pe...@stuge.se napisał(a):
Freddie Chopin 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, so that's not a good
Xiaofan Chen xiaof...@gmail.com 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
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 /
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 add a
On Friday 29 October 2010 08:18:46 Marek Vasut wrote:
On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut
marek.vasut.n...@gmail.com wrote:
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut
marek.vasut.n...@gmail.com wrote:
Shouldn't this be automatically detected?
yes it
On Fri, Oct 29, 2010 at 9:33 AM, Marek Vasut marek.va...@gmail.com 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
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
2010/10/29 freddie_cho...@op.pl:
Xiaofan Chen xiaof...@gmail.com 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
On Fri, Oct 29, 2010 at 2:43 PM, Peter Stuge pe...@stuge.se 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
Xiaofan Chen xiaof...@gmail.com 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
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.
BTW I
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?
Ø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 even in there
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,
2010/10/29 freddie_cho...@op.pl:
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
On Fri, Oct 29, 2010 at 10:24 AM, Peter Stuge pe...@stuge.se 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
Peter Stuge pe...@stuge.se 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
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 pe...@stuge.se 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
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'
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,
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
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 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
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 ch...@martin-jones.com wrote:
Hi all,
I'm using
On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones ch...@martin-jones.com 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
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 ... and I
31 matches
Mail list logo
