On Tue, May 19, 2009 at 8:53 AM, Spencer Oliver wrote:
>
>> Does the LPC2148 (which I have) exhibit the same problem?
>>
>> I can not test the attached patch here, but it is intended to
>> allow switching between the long(old) or new (short)
>> tms_sequence tables. The patch uses the short table a
> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de
> [mailto:openocd-development-boun...@lists.berlios.de] Namens
> Zach Welch
> Verzonden: dinsdag 19 mei 2009 7:49
> Aan: openocd-development
> Onderwerp: [Openocd-development] milestone strategy [3 of 4]
>
>
> Does the LPC2148 (which I have) exhibit the same problem?
>
> I can not test the attached patch here, but it is intended to
> allow switching between the long(old) or new (short)
> tms_sequence tables. The patch uses the short table as default.
>
> Try:
>
> tms_sequence long
> tms_sequence
On Tue, May 19, 2009 at 2:38 PM, Spencer Oliver wrote:
>
> I have tested both the filter and native driver under winxp.
> Never tested the filter driver under vista64, but the native driver works.
>
Thanks for the confirmation. I will try out the libusb-win32 device driver
for Windows Vista 32bit
> The other choice is to use the libusb-win32 device driver.
> In that case, you create the INF using the INF wizard and
> replace the stock Segger driver with libusb-win32 device
> driver.It works better than the filter driver and works under
> Vista 32 bit. But in this case, you can no longer
On Tue, 2009-05-19 at 08:04 +0200, Øyvind Harboe wrote:
> > - J-link stability and compatibility
> > - CFI driver chip/bus width issues (status??)
> > - PIC32 support (long-term)
>
> Should we make the old tms sequences default for 0.2? I don't like it
> from the point of view that we can't then *
> - J-link stability and compatibility
> - CFI driver chip/bus width issues (status??)
> - PIC32 support (long-term)
Should we make the old tms sequences default for 0.2? I don't like it
from the point of view that we can't then *force* users to test it.
https://lists.berlios.de/pipermail/openocd
Hi all,
Since this weekend, I have spent some time working on a set of Perl
scripts to prototype the back-end system that will aggregate the data
and present it for review (pre-analysis).
I started on this to replace the static developer table that I was using
to augment The List. I think most
Hi all,
In tandem to perpetual tactical quality-improvement release goals, the
OpenOCD community will be pursuing strategic development goals that lead
to special "milestone" releases. As this indicates, I think such
planning should be decoupled from the release process, in so far as we
should be
Hi all,
This message tries to cover a proposal for a tactical release "process"
for the OpenOCD community to consider. If there seems to be agreement
that this will be acceptable, I will write start some the relevant bits
up in a document and add it to the reference manual.
At the moment, we ar
On Tue, May 19, 2009 at 1:33 PM, Rick Altherr wrote:
> OpenOCD certainly supports more than just FT2232. At the moment, there is
> support for FT2232, JLink, RLink, VSLLink, and usbprog. I don't know of any
> reason why these won't work on Windows. All of the USB-based interfaces use
> libusb
Hi all,
I updated The List in r1828 (see the TODO file) to help prepare the
OpenOCD project for its forthcoming 0.2.0 release. Please review it to
make sure that it contains the features that you want OpenOCD to have
before it is "done" (not only for 0.2.0). Please reply to this thread
with patc
Hi all,
I have prepared the following e-mails to attempt to move the OpenOCD
release process into motion, breaking out some various policies for
managing our ongoing releases and milestones that should also give us
some degree of quality-assurance. These cover several related (but
separable) topi
On May 18, 2009, at 6:24 PM, Xiaofan Chen wrote:
Does OpenOCD supports J-Link under Windows?
From here it seems to be no. And the front page OpenOCD
only supports ftdi2232.
http://www.yagarto.de/howto/jlink/index.html
The drive is certainly an issue. libusb-win32 filter driver may
be an option
On Mon, May 18, 2009 at 11:09 PM, Gene Smith wrote:
> Mine says: Updating firmware: J-Link compiled Feb 20 2006 18:20:20 --
> Update --
> Mine says: Replacing firmware J-Link compiled Dec 2 2004 09:13:33
> Mine says: S/N : -3
Kind of strange. Could you try the segger utilities under Windows?
C:\
2009/5/19 Michel Catudal :
> The mips debugger should work with it but you need some way to flash the
> program.
> I am busy working on the programmer. When I get something working I will
> submit it as well as my debugger and eclipse support.
>
That would be great. I have the PICKit 2 which work
Xiaofan Chen a écrit :
> As far as I know, the chip erase is not implemented/working
> for flashing the PIC32 according to the mailing list archive. So
> it might be barely working. I do not know the status of debugging.
>
>
The mips debugger should work with it but you need some way to flash t
On Sun, 17 May 2009, David Brownell wrote:
> The following are some notes I put together about the "nand"
> commands based on reading the source code.
>
> I plan to turn them into documentation sometime later, maybe by this
> time next week. I've seen no documentation on the NAND commands; that
Does OpenOCD supports J-Link under Windows?
>From here it seems to be no. And the front page OpenOCD
only supports ftdi2232.
http://www.yagarto.de/howto/jlink/index.html
The drive is certainly an issue. libusb-win32 filter driver may
be an option but it is known to break things under Vista 32
and
Hello Benjamin,
Tuesday, May 19, 2009, 2:48:30 AM, you wrote:
BS> I think this wouldn't hurt anyone and could be very useful for debugging
like
BS> this.
BS> But it should definately check via EMU_CMD_GET_CAPS first if command is
BS> available. At the moment the caps value is read from the devi
Hello Igor
I think this wouldn't hurt anyone and could be very useful for debugging like
this.
But it should definately check via EMU_CMD_GET_CAPS first if command is
available. At the moment the caps value is read from the device but for
example the call to EMU_CMD_GET_MAX_MEM_BLOCK is done o
Hello Benjamin,
Tuesday, May 19, 2009, 12:39:26 AM, you wrote:
BS> There's this segger closed source linux gdm server tool...
BS> http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz
BS> It can show the hardware version.
Is there a necessity to map missing JLink commands? I could find them
o
Does either rev 1833 or 1833 with my patch displaying something like this in
the beginning?
Info : J-Link compiled Feb 20 2006 18:20:20 -- Update --
Info : JLink caps 0x3
Info : JLink max mem block 32
Info : Vref = 3.283 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 1 TRST = 255
The problem is that my
On Sat, May 16, 2009 at 6:38 AM, Dean Glazeski wrote:
> On another note, I'm going to start working harder with Chitlesh Goorah,
> CC'd, on packaging the RPM for Fedora for OpenOCD. Chitlesh has a desire to
> get OpenOCD pushed into the Fedora Electronics Lab (FEL) distribution and I
> really wan
Benjamin Schmidt wrote:
> There's this segger closed source linux gdm server tool...
>
> http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz
>
>
>
> It can show the hardware version.
With patch still gets three EMU_CMD_GET_CAPS errors and "don't worry".
Then LED goes off on jlink. Shoul
On Mon, 18 May 2009, Peter Denison wrote:
> Now, on to the actual crash. I will do more investigation, but for now,
> here's the backtrace:
>
> Starting program: /src/.libs/lt-openocd -f
> ../../../openocd-usr8200-jlink.cfg
> Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827
There's this segger closed source linux gdm server tool...
http://www.segger.com/pub/jlink/JLink_Linux_090202.tar.gz
It can show the hardware version.
On Monday 18 May 2009 11:24:51 pm Gene Smith wrote:
> Benjamin Schmidt wrote:
> > Hello,
> >
> > I posted a similar patch several month ago
> > Gentlemen,
> > AFAIK EJTAG is already implemented in OpenOCD (I'm using it for
> > another MIPS based SOC to program external flash). I just
> don't know
> > how complete it is in respect to debugging/single stepping.
> The flash
> > programming routines for PIC32 are also available in Ope
Benjamin Schmidt wrote:
> Hello,
>
> I posted a similar patch several month ago.
> I have a JLink version v3.0
>
> To get it to work you have to change several little things.
>
> This is just a very ugly hack that somewhat disables support for >=V5 JLinks
>
> I'd just be interested if any of yo
> > Try using
> >
> > libtool gdb ../openocd
> >
> > or the more pedantic (but future-proof):
> >
> > libtool --mode=execute gdb ../openocd
>
> Once a solution has been identified, it would be nice to have
> the BUGS file updated...
>
> --
for dev work it is often easier to config
Hello,
I posted a similar patch several month ago.
I have a JLink version v3.0
To get it to work you have to change several little things.
This is just a very ugly hack that somewhat disables support for >=V5 JLinks
I'd just be interested if any of you can also get it to work this way...
I woul
Committed 1833
use tap_get_tms_path_len() instead of fix # of 7 for all interfaces.
Not tested if this builds, but at least we're looking at a build error
instead of a runtime error.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
On Mon, 18 May 2009, Øyvind Harboe wrote:
Try using
libtool gdb ../openocd
or the more pedantic (but future-proof):
libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
Excellent! That (to be precise the
On Mon, 2009-05-18 at 21:51 +0200, Øyvind Harboe wrote:
> > Try using
> >
> >libtool gdb ../openocd
> >
> > or the more pedantic (but future-proof):
> >
> >libtool --mode=execute gdb ../openocd
>
> Once a solution has been identified, it would be nice to have the BUGS
> file update
Minor NAND updates:
- Comment which IDs are "museum" IDs: obsolete first-gen parts,
some with IDs that are reused with newer parts, 256-byte pages.
Linux doesn't support these by default, and OpenOCD rejects
the 256-byte pages.
- Recognize Micron as a NAND manufacturer.
- For "nand
Does the LPC2148 (which I have) exhibit the same problem?
I can not test the attached patch here, but it is intended
to allow switching between the long(old) or new (short)
tms_sequence tables. The patch uses the short table
as default.
Try:
tms_sequence long
tms_sequence short
--
Øyvind Harbo
> Try using
>
> libtool gdb ../openocd
>
> or the more pedantic (but future-proof):
>
> libtool --mode=execute gdb ../openocd
Once a solution has been identified, it would be nice to have the BUGS
file updated...
--
Øyvind Harboe
Embedded software and hardware consulting services
h
On Mon, 2009-05-18 at 19:33 +0100, Peter Denison wrote:
> On Mon, 18 May 2009, Øyvind Harboe wrote:
>
> [Oops - failed to copy the original to the list...]
> > On Mon, May 18, 2009 at 8:21 AM, Peter Denison
> > wrote:
> >> On Sat, 16 May 2009, Øyvind Harboe wrote:
> >>
> >>> Could you post a GDB
On Monday 18 May 2009, Dean Glazeski wrote:
> Do you mean the target_type_s and target_s structures? I think there may be
> some others too like the arm7_9_common_s struct. I'm commenting up the
> arm7_9_common_s struct as I go too.
Yes, those interfaces. Once those get properly documented,
the
On Mon, 18 May 2009, Øyvind Harboe wrote:
$ gdb ../openocd --args openocd
... ends up running /usr/bin/openocd ...
Try
gdb --args openocd -f interface/xxx.cfg -f target/.cfg ...
This runs the one (r1409) in /usr/bin, not my newly compiled one.
If I find the actual executable, which I
Hello Rick,
the 1825 works better than the 1827, take a look at the OpenOCD output.
In case of the 1827 I got a "Error: JTAG communication failure" first.
Attached are the log and cfg files. Tested under Windows with a FT2232
device (JTAGkey) and a LPC2294 cpu.
Best regards,
Michael
OpenoCD -
On Monday 18 May 2009, Dirk Behme wrote:
>
> > Any thoughts on how OpenOCD could be made clearer at this point?
>
> Some additional printfs and/or error messages? E.g.
>
> - When init is executed 'automatically' at startup:
>
> printf("Info: init successfully done\n");
>
> - When you try to do
> $ gdb ../openocd --args openocd
> ... ends up running /usr/bin/openocd ...
Try
gdb --args openocd -f interface/xxx.cfg -f target/.cfg ...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Open
On Mon, 18 May 2009, Øyvind Harboe wrote:
[Oops - failed to copy the original to the list...]
On Mon, May 18, 2009 at 8:21 AM, Peter Denison wrote:
On Sat, 16 May 2009, Øyvind Harboe wrote:
Could you post a GDB backtrace?
See:
http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
I trie
Øyvind Harboe wrote:
> On Mon, May 18, 2009 at 7:55 PM, Dirk Behme wrote:
>> Ųyvind Harboe wrote:
>>> You can't use "target create" on the telnet command line
>>> because it is after "init". If "init" is not on the command
>>> line, OpenOCD runs it before launching the telnet
>>> server.
>> Ah, t
On Mon, May 18, 2009 at 7:55 PM, Dirk Behme wrote:
> Ųyvind Harboe wrote:
>>
>> You can't use "target create" on the telnet command line
>> because it is after "init". If "init" is not on the command
>> line, OpenOCD runs it before launching the telnet
>> server.
>
> Ah, that explains a lot! ;) W
Raúl Sánchez Siles wrote:
> Hello All:
>
> Thanks a lot for the prompt answers, unlike this e-mail. I've been off from
> the office since my post, so sorry for it.
>
> I now notice I failed to provide sufficient details about the issue at
> discussion. The flash uses is a 16bit data width,
Øyvind Harboe wrote:
> You can't use "target create" on the telnet command line
> because it is after "init". If "init" is not on the command
> line, OpenOCD runs it before launching the telnet
> server.
Ah, that explains a lot! ;) Will try it.
Thanks
Dirk
_
You can't use "target create" on the telnet command line
because it is after "init". If "init" is not on the command
line, OpenOCD runs it before launching the telnet
server.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_
I merged in the updated version of Dick's changes as 4 separate patches:
- r1812 updates the state table but does not enable the "short" table
- r1825 has the FT2232 fixes for supporting the short table
- r1826 has the JLink fixes for supporting the short table
- r1827 enables the short table if
Øyvind Harboe wrote:
> You have to create the target before the init command.
>
> One could talk about allowing targets to be created/deleted
> on the fly, but OpenOCD isn't at that stage today.
>
>
> This works:
>
> openocd -s lib/openocd/ -f interface/dummy.cfg -f target/omap3530.cfg
> -c "ta
On May 17, 2009, at 1:51 AM, Michael Bruck wrote:
The code in jtag.c currently manipulates the command queue pointers
directly in every function. This increases potential for errors and
makes the code less readable by distracting the reader from the core
algorithm contained in every function.
Xiaofan Chen wrote:
> On Mon, May 18, 2009 at 9:37 PM, Gene Smith wrote:
>> I can't answer your questions but can only add another jlink question. I
>> know very little about the jlink. I have a yellow jlink that says "jlink
>> ks, IAR Systems" on the front (ks = kickstart?). On the back it says
>
On Mon, May 18, 2009 at 3:36 PM, Nico Coesel wrote:
> Gentlemen,
> AFAIK EJTAG is already implemented in OpenOCD (I'm using it for another
> MIPS based SOC to program external flash). I just don't know how
> complete it is in respect to debugging/single stepping. The flash
> programming routines
More tests on flash writing. I got the script from psas. Maybe it is too
old (for V1257). I will try later with new scripts.
http://www.linuxjournal.com/article/10421
With black J-link
> script oocd_flash_lpc2148.script
J-Link command 0xdd failed (-2)
J-Link command 0xde failed (-2)
J-Link command
On Mon, May 18, 2009 at 10:18 PM, Xiaofan Chen wrote:
> mc...@ubuntu904:~/Desktop/build/openocd/jlinknew$ openocd -f
> openocd_lpc2148.cfg
> Open On-Chip Debugger 0.2.0-in-development (2009-05-18-19:51) svn:1809
>
>
> BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
>
>
> $URL: s
On Mon, May 18, 2009 at 9:37 PM, Gene Smith wrote:
> I can't answer your questions but can only add another jlink question. I
> know very little about the jlink. I have a yellow jlink that says "jlink
> ks, IAR Systems" on the front (ks = kickstart?). On the back it says
> J-Link-ARM-KS Serial Num
On Mon, May 18, 2009 at 3:53 PM, Øyvind Harboe wrote:
>> I broke it down as small as possible. The change is trivial. I tested
>> it here as far as possible. I can't test *all* of the functions as my
>> target doesn't use them, but again, the rewrite is absolutely trivial.
>
> Did Rick want someth
Committed.
Remove unecessary(and poptentially harmful?) "" around arguments
passed in to "eval" in command.c
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/command.c
===
--- src/helper/command.c(revision 1806)
> I broke it down as small as possible. The change is trivial. I tested
> it here as far as possible. I can't test *all* of the functions as my
> target doesn't use them, but again, the rewrite is absolutely trivial.
Did Rick want something *else* or something *more*?
If he wanted something *more
On Mon, May 18, 2009 at 3:28 PM, Øyvind Harboe wrote:
> If you post patches and vouch for them, then I, or another committer
> who beats me to it, will commit them promptly.
>
> Currently the problem is that there are patches posted, but nobody
> has time to say anything as to whether they are rea
Xiaofan Chen wrote:
> 2008/12/25 Michel Catudal :
>> I could not get my older black j-link devices to work while the newer yellow
>> one works. I am curious as to what the basic difference would be between
>> the two. I tested them at work and they were working just as good on windows
>> as the yel
If you post patches and vouch for them, then I, or another committer
who beats me to it, will commit them promptly.
Currently the problem is that there are patches posted, but nobody
has time to say anything as to whether they are ready for testing.
I think it would be *greatly* helpful if we cou
> It's even easier than that :-)
>
> jtag.c needs a few tweaks and a bit of testing and it can be committed
> first without further ado. It just needs "someone" to step up to the plate
> and take charge.
>
> https://lists.berlios.de/pipermail/openocd-development/2009-May/006586.html
>
> I suspect t
Hey David,
Do you mean the target_type_s and target_s structures? I think there may be
some others too like the arm7_9_common_s struct. I'm commenting up the
arm7_9_common_s struct as I go too.
// Dean Glazeski
On Mon, May 18, 2009 at 2:37 AM, David Brownell wrote:
> On Sunday 17 May 2009, D
Committed.
The _ trick to handle two level commands, e.g. "flash banks", no longer
causes weird error messages w/"_" appearing.
Example of new error message:
> flash nosupported s adsfads asf saf
Unknown command: flash nosupported s adsfads asf saf
called at file "command.c", line 453
### Ecli
> Then why not just copy the current trunk to something like
> branches/merge-ftd2232-vs-r1809 and then commit the change there so
> that it can be tested?
It's even easier than that :-)
jtag.c needs a few tweaks and a bit of testing and it can be committed
first without further ado. It just need
On Mon, May 18, 2009 at 1:24 PM, Øyvind Harboe wrote:
>> Do we have a time frame for that? Can't Magnus split these changes up
>> into small independent pieces and commit them to the trunk regularly?
>> This way he can update his working tree from the trunk and get my and
>> other's commits withou
> Do we have a time frame for that? Can't Magnus split these changes up
> into small independent pieces and commit them to the trunk regularly?
> This way he can update his working tree from the trunk and get my and
> other's commits without everybody's work stalling until he has
> finished the who
On Mon, May 18, 2009 at 11:25 AM, Øyvind Harboe wrote:
> On Mon, May 18, 2009 at 11:12 AM, Michael Bruck wrote:
>> On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe
>> wrote:
I agree. I'll get to reviewing the patches in depth tonight and hopefully
get them committed.
>>>
>>> It would
Hello All:
Thanks a lot for the prompt answers, unlike this e-mail. I've been off from
the office since my post, so sorry for it.
I now notice I failed to provide sufficient details about the issue at
discussion. The flash uses is a 16bit data width, but it is connected using
just 8 bit
On Mon, May 18, 2009 at 11:12 AM, Michael Bruck wrote:
> On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe
> wrote:
>>> I agree. I'll get to reviewing the patches in depth tonight and hopefully
>>> get them committed.
>>
>> It would be great to have Magnus Lundin's changes committed too, just
>>
On Mon, May 18, 2009 at 10:56 AM, Øyvind Harboe wrote:
>> I agree. I'll get to reviewing the patches in depth tonight and hopefully
>> get them committed.
>
> It would be great to have Magnus Lundin's changes committed too, just
> to keep things in sync...
>
Which ones do you mean ?
Michael
___
On Mon, May 18, 2009 at 6:51 AM, Rick Altherr wrote:
>
> On May 17, 2009, at 2:40 PM, Michael Bruck wrote:
>
>> - remove stale interdepencies between arm11 and arm7_9_common
>> - added comments
>> - fixed some indentation
>>
>>
>> Michael
>> ___
>> Openo
> I agree. I'll get to reviewing the patches in depth tonight and hopefully
> get them committed.
It would be great to have Magnus Lundin's changes committed too, just
to keep things in sync...
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
> -Oorspronkelijk bericht-
> Van: openocd-development-boun...@lists.berlios.de
> [mailto:openocd-development-boun...@lists.berlios.de] Namens Strontium
> Verzonden: maandag 18 mei 2009 4:06
> Aan: Xiaofan Chen
> CC: openocd-development@lists.berlios.de
> Onderwerp: Re: [Openocd-developme
What could be going on is that the verify algorithm, which
runs on the target, crashed somehow.
Here is essentially what verify does:
1. uploads a small application to the target
2. this app runs a crc on the flash
3. OpenOCD checks that the crc is correct
Try a "reset init" before you run verif
On Mon, May 18, 2009 at 6:36 AM, Rick Altherr wrote:
>
> On May 17, 2009, at 9:03 PM, David Brownell wrote:
>
>> On Friday 15 May 2009, Øyvind Harboe wrote:
>>>
>>> So apply this patch?
>>>
>>> Can anyone test?
>>>
>>> jtagpatch.txt
>>
>> It failed for me on an ft2232 device.
>>
>
>
> Hmm. It loo
Committed in 1809
I missed the bugfix/typo until I reviewed your code :-)
Thanks!
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
___
Openocd-development mailing list
Openocd-development@lists.berlios.d
Committed.
I've updated the copyright notice so that it is clear that Michael Bruck
is the first author(even if the copyright is held by someone else).
Let me know if it needs updating.
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
_
80 matches
Mail list logo
