Re: [Openocd-development] Command-line paths problem in Windows

[Andrew Leech]

On 21/10/2011 3:04 AM, Freddie Chopin wrote:
1. In 0.5.0 you could use slash or backslash (which is more "correct" 
in Windows) - no difference. Now only slash works, backslash is 
ommited and replaced with... nothing...
2. When running OpenOCD as External Tool from Eclipse I always left 
"Working Dir" empty and it worked fine, now I have to specify this 
directory for OpenOCD to work - probably because backslashes in 
Windows paths are replaced with nothing...


Have you tried with double backslash "\\" ?
I've become very used to windows/cygwin/openocd/eclipse/make all 
behaving very differently when it comes to slashes, and trying to make 
various different tools work together through eclipse or makefiles can 
be quite frustrating when they use incompatible paths. The same can be 
said for ' and ", both can be useful in some cases when building paths 
with spaces, but both can also break things in other apps.
I don't know anything about who/what changed the handling in openocd, 
although if it's been done on purpose to make its handling more 
consistent or compatible with other parts of the toolchain I'd think 
it's worthwhile, although it doesn't sound like that is the case, it's 
certainly sounding worse in eclipse going by your description.


Either way, I generally us the \\ as the most compatible path separator 
on windoze, although there's still some apps that don't like that 
either, and it isn't any good if you want to make cross platform config 
files


Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Fwd: ft2232_transfer why bit-by-bit?

[Andrew Leech]

On 27/09/2011 7:37 AM, Akos Vandra wrote:

-- Forwarded message --
From: Akos Vandra
Date: 26 September 2011 23:36
Subject: Re: [Openocd-development] ft2232_transfer why bit-by-bit?
To: Laurent Gauch


Hi!

Sorry, it seems like I wanted to do too much too fast. Turns out I
don't have an SWD compatible programmer yet. I am going to make a
programmer compatible with kt_link_swd.
I found its pinout over the internet, and I am currently making up the
schematic.

Does anyone by chance have designs for such a programmer, that I could
build myself? I find 50E too much for the kt_link.
If not, I might release the gerber files to the public.

Regards,
  Ákos
The only other one I know of is the TI/Luminary ICDI adapter. This comes 
with a number of the LM3S series eval kits, and the schematic for it is 
in the user manuals for said kits. One like this (page 31): 
http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=spmu036g&fileType=pdf 
 


or (page 22 & 23) http://www.ti.com/lit/ug/spmu034c/spmu034c.pdf
They don't provide gerbers, but the pics on page 25 of the second one 
will give you an idea of a basic layout that can work.
I think TI's ft2232 layout is different to the kt-link though, so will 
require a minimal amount of code adding to make it work on the current 
swd code.


Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Halt times out on a LPC3131 board during reset

[Andrew Leech]

tly reliable connection 
sequence in eclipse. Earlier with less/different commands it would 
sometimes connect, other times have halt timed out etc.


Good Luck,
Andrew Leech
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Supported FTDI SWD layouts

[Andrew Leech]

On 14/07/2011 10:43 PM, Xiaofan Chen wrote:

On Thu, Jul 14, 2011 at 8:33 PM, Uwe Bonnes
  wrote:

Hello,

are there any other published FTDI->SWD hardware setup beside KTLINL
http://sourceforge.net/apps/mediawiki/stm32primer2swd/index.php?title=File:Ktlink-buffers.png
that support SWD and are supported by openocd?

Maybe that is the only one.

This one may be possible as well.
http://www.seeedstudio.com/depot/bus-blaster-v2-jtag-debugger-p-807.html
http://dangerousprototypes.com/docs/Bus_Blaster_v2_buffer_logic


The Luminary/TI ICDI schematic is also available, in a few of the 
stellaris dev kit user guides such as the ek-lm3s9b90:

http://focus-webapps.ti.com/general/docs/sitesearch/searchdevice.tsp?partNumber=ek-lm3s9b90
http://focus.ti.com/lit/ug/spmu034b/spmu034b.pdf

I don't know that this SWD layout has planned support yet, but there's 
no reason it wont be easily possible once SWD is up and running.


Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD 0.5.0-rc2 release

[Andrew Leech]

On 13/07/2011 11:48 AM, Peter Stuge wrote:

Andrew Leech wrote:

Again just a release tarball issue, but the tarball from above doesn't work
properly, it needs bootstrap run to get jimtcl etc

In particular for a release it's really really important that the two
separate packages (OpenOCD and jimtcl) are *two separate packages*.

The tricks that autobuild jimtcl are convenient for random perusal
but does not very nice packaging make.
From a user perspective, I find the automatically handled jimtcl 
compiling to be of enormous benefit. I know there have been huge debates 
in the area already though, so don't want to go into it too much, but 
the current system does make compiling (for new users) far easier.

specify the full mingw gcc name as per below or CC="gcc-3 -mno-cygwin"
(which I haven't tested recently):
Using: $ ./configure  --enable-maintainer-mode --enable-ft2232_ftd2xx
--with-ftd2xx-win32-zipdir=../ftdi CC="i686-pc-mingw32-gcc"

CC should basically *never* be used. --host=i686-pc-mingw32 should be
given to configure in this case, with no environment variables.

Thanks for that, I guess I did know that's what --host does, I'd just forgotten 
in this context. For what it's worth I recompiled after a reconfigure with 
--host=i686-pc-mingw32 and got a working openocd.exe :-D


I also had problems with jimtcl and dos line ends, the configure
scripts and autosetup files didn't work

Nod. For unknown reason at least configure absolutely must have LF
only line endings.
The problems I was getting appeared to be / problems, ie it was stuffing 
up directory paths. I didn't chase down the original source of them 
though...

Could bootstrap have it's git commands for pulling jimtcl changed
to ensure it doesn't save in dos mode?

Rather difficult. Unsure how that would be done if at all. What could
be done is to add eol=lf in .gitattributes for the files that need it.
Or at least make a mention of this in the README.Win32 (and possibly in 
HACKING as well) as something to watch out for, and how to rectify it.

Debugging a lpc3131 (ARM926EJ-S) with a ft2232 jtagkey compatible
dongle then works fine!

Thanks for writing up the build issues and testing!

Thanks for the feedback!
Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] OpenOCD 0.5.0-rc2 release

[Andrew Leech]

On 11 July 2011 07:31, Jean-Christophe PLAGNIOL-VILLARD 
 wrote:

rc2

http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=snapshot;h=d4cd6f032015552f00bf4b5a90f25f5f958e9d9e;sf=tgz



I'm assuming some testing would be good :-)  I'm just moving into a 
firmware project again, so a good opportunity, recompiling from this tgz 
now. I'm been compiling from git occasionally for a long time now, it's 
been a while since starting from a fresh release. using Windows 7 x64, 
cygwin compiling.


Couple of comments:
Firstly, the docs in the tarball could do with some updating, sorry I 
don't have time to do it just now.


README.Win32 mentions "The Cygwin/Win32 ZIP file contains a directory 
named ftd2xx.win32". This doesn't exist, will it be included in a proper 
release tarball, or are these referring to the ftdi files that can't be 
distributed legally?


Similarly the ./bootstrap command is only mentioned at the end of 
README, while I'm guessing that this wont be needed in a release 
tarball, if anyone who does need it tried to follow the readme linearly 
they'll run into problems before finally finding this down the bottom, I 
feel it should probably be mentioned earlier up.


Again just a release tarball issue, but the tarball from above doesn't 
work properly, it needs bootstrap run to get jimtcl etc, but I get:

$ ./bootstrap
+ aclocal
+ libtoolize --automake --copy
+ autoconf
+ autoheader
+ automake --gnu --add-missing --copy
configure.in:20: installing `./compile'
configure.in:28: installing `./config.guess'
configure.in:28: installing `./config.sub'
configure.in:8: installing `./install-sh'
configure.in:8: installing `./missing'
doc/Makefile.am:1: installing `doc/mdate-sh'
doc/Makefile.am:1: installing `doc/texinfo.tex'
src/Makefile.am: installing `./depcomp'
Makefile.am: installing `./INSTALL'
Setting up submodules
fatal: Not a git repository (or any parent up to mount parent /cygdrive)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

It expects the openocd dir to be a git repository, but this tarball 
isn't. Nasty workaround I copied .git from my existing openocd 
source folder into the tarball folder and that got me jimtcl and the 
rest of the way through bootstrap.


I think README.Win32 should be updated regarding gcc options, mentioning 
that using default gcc will result in cygwin dependency, or alternately 
install cygwin packages for mingw and then specify the full mingw gcc 
name as per below or CC="gcc-3 -mno-cygwin" (which I haven't tested 
recently):
Using: $ ./configure  --enable-maintainer-mode --enable-ft2232_ftd2xx 
--with-ftd2xx-win32-zipdir=../ftdi CC="i686-pc-mingw32-gcc"


I also had problems with jimtcl and dos line ends, the configure scripts 
and autosetup files didn't work, spitting some nasty errors because of 
dos line ends... this took me a while to debug. Could bootstrap have 
it's git commands for pulling jimtcl changed to ensure it doesn't save 
in dos mode?
Once I did a $ fromdos jimtcl/* and $ fromdos jimtcl/autosetup* 
configure passed just fine.


make completed with no issues.
Debugging a lpc3131 (ARM926EJ-S) with a ft2232 jtagkey compatible dongle 
then works fine!


Cheers,
Andrew


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Hi level debug application

[Andrew Leech]

On 11/07/2011 9:08 PM, Hard Maker wrote:

Hi List,
I'm starting with OpenOCD and have a questions about wath hi level 
application can use with openOCD. Basically I need/want run 
aplications and know the var values. Using OpenOCD I can flash, view 
registry state, run, etc. But there are some aplication to do a trace 
more easy?
I'm try with Code::Blocks and Insight using remote debuging with no 
luck. Someone use OpenOCD with hi level aplications to debug? Wath 
application ar using?

Thank's a lot

Sergio


Hi Sergio,
The most common high level ide in use with openocd would have to be 
eclipse. It takes a fair bit of getting used to I found, what with it's 
settings all over the place, manual project configuration and workspace 
based project management, but once you've figured it out it works quite 
well.
Just google openocd eclipse open-source toolchain and similar and you'll 
find heaps of different setup guides, or you might like to look at 
sdk4arm from amontec as a bit of a head start (I haven't tried it though).


Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slow pipe usage (was eclipse indigo)

[Andrew Leech]

On 5/07/2011 8:36 AM, Andrew Leech wrote:

On 4/07/2011 6:22 PM, Spencer Oliver wrote:

On 4 July 2011 08:12, Andrew Leech  wrote:

On 1/07/2011 8:47 PM, Spencer Oliver wrote:

On 1 July 2011 00:41, Andrew Leechwrote:
Only problem is, it's incredibly slow, unusably slow. A single 
step can

take
5 seconds, where on a normal tcp connection with same configs 
feels close

to
instant, so maybe about 1/4 of a second. Did your windows one behave
better?
If so, do you know what version/release of gdb you used?

used Sourcery G++ Lite 2011.03-42
Have not noticed any speed issues, most of my testing was under linux
however.
I am running winxp, that has always proved fairly nippy compared to
vista anyway.



Delving into openocd logs, taking a -d3 on both pipe and tcp usage, 
I get
exactly the same commands being run for both when stepping over the 
first

line of my program, but in pipe usage lots of them take 100ms longer:


That 100ms may well be caused by the win32 version of select - win32
select does not support pipes so had to create a special version.
Check out the MsgWaitForMultipleObjects and you see your 100ms delay.

Perhaps this function needs tweaking.

Cheers
Spen


If it's a code issue with openocd code, I would have thought you'd see 
the same problem in pipe mode on windows, I know you said you never 
used it much, but I find it's instantly noticeable, around a factor of 
10 different in speed.


With all this playing around though, I've also found that openocd 
doesn't shut down properly in pipe mode with eclipse, neither hitting 
terminate not disconnect in eclipse will actually shut down openocd or 
gdb, they just sit there hanging. I just have to resort to task 
manager to shut it down. Maybe I'll just have to stick with using 
openocd as a separate external tool still. Unfortunately I'm locked to 
windows for using Altium Deisgner (my main role is electroncis 
design), and I just get sick of trying to do too much in vm's.


Thanks,
Andrew



Thanks for the tip about MsgWaitForMultipleObjects, I went hunting. It's 
not the timeout on that call that causes the delay, but the 
tvslice.tv_usec setting above it. In particular:

diff --git a/src/helper/replacements.c b/src/helper/replacements.c
index ef20e77..00e6bd1 100644
--- a/src/helper/replacements.c
+++ b/src/helper/replacements.c
@@ -216,7 +216,7 @@ int win_select(int max_fd, fd_set *rfds, fd_set 
*wfds, fd_set *efds, struct time

aexcept = sock_except;

tvslice.tv_sec = 0;
-   tvslice.tv_usec = 10;
+   tvslice.tv_usec = 3;

retcode = select(sock_max_fd + 1, &aread, 
&awrite, &aexcept, &tvslice);

}

Speeds up stepping dramatically (about 3 x faster ;-)
I have a feeling it makes other things a little less reliable, I seemed 
to have more trouble connecting to my target, but then connecting to my 
target goes through phases of being difficult, there's some other 
settings that I've never got completely ironed out. So I don't know if 
this change is really what made it worse, or if it's unrealted.


Either way I'll leave my local copy like this for now and give it a go, 
but if I get a chance I'll have a look deeper into whether there's a 
better way of doing it don't know if/when that may ever happen though.


Thanks,
Andrew

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slow pipe usage (was eclipse indigo)

[Andrew Leech]

On 4/07/2011 6:22 PM, Spencer Oliver wrote:

On 4 July 2011 08:12, Andrew Leech  wrote:

On 1/07/2011 8:47 PM, Spencer Oliver wrote:

On 1 July 2011 00:41, Andrew Leechwrote:

Only problem is, it's incredibly slow, unusably slow. A single step can
take
5 seconds, where on a normal tcp connection with same configs feels close
to
instant, so maybe about 1/4 of a second. Did your windows one behave
better?
If so, do you know what version/release of gdb you used?

used Sourcery G++ Lite 2011.03-42
Have not noticed any speed issues, most of my testing was under linux
however.
I am running winxp, that has always proved fairly nippy compared to
vista anyway.



Delving into openocd logs, taking a -d3 on both pipe and tcp usage, I get
exactly the same commands being run for both when stepping over the first
line of my program, but in pipe usage lots of them take 100ms longer:


That 100ms may well be caused by the win32 version of select - win32
select does not support pipes so had to create a special version.
Check out the MsgWaitForMultipleObjects and you see your 100ms delay.

Perhaps this function needs tweaking.

Cheers
Spen


If it's a code issue with openocd code, I would have thought you'd see 
the same problem in pipe mode on windows, I know you said you never used 
it much, but I find it's instantly noticeable, around a factor of 10 
different in speed.


With all this playing around though, I've also found that openocd 
doesn't shut down properly in pipe mode with eclipse, neither hitting 
terminate not disconnect in eclipse will actually shut down openocd or 
gdb, they just sit there hanging. I just have to resort to task manager 
to shut it down. Maybe I'll just have to stick with using openocd as a 
separate external tool still. Unfortunately I'm locked to windows for 
using Altium Deisgner (my main role is electroncis design), and I just 
get sick of trying to do too much in vm's.


Thanks,
Andrew

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slow pipe usage (was eclipse indigo)

[Andrew Leech]

On 4/07/2011 5:26 PM, Xiaofan Chen wrote:

On Mon, Jul 4, 2011 at 3:12 PM, Andrew Leech  wrote:

Stepping is still slow though. I'm wondering if this is related to my cygwin
on this machine, I've noticed that configure scripts on anything run
incredibly slowly, never found out why. I decided to cross compile openocd
from linux to rule out any issues from compiling with my cygwin (even though
I used the mno-cygwin flag) but this also didn't make any difference. I'm
not sure, maybe cygwin is stuffing up port's still or something.
...
Just had an idea, and now I definitely think it's a system wide pipe issue;
from cygwin prompt:
$ time echo "blah"
blah

real0m0.001s
user0m0.000s
sys 0m0.000s

$ time echo "blah" | cat
blah

real0m0.151s
user0m0.031s
sys 0m0.030s

Darn, might have to hit up the cygwin guys for help.

I do not think this has anything to do with your OpenOCD problem.
Cygwin is known to be slow. MSys is faster but still slower than Linux.

I do not know what you want to show by the bash commands though.
Anyway, here are my results on a Core i5 Notebook (Dell Latitude E6410,
XP SP3, Latest Cygwin).

bash-4.1# time echo "blah"
blah

real0m0.002s
user0m0.000s
sys 0m0.000s
bash-4.1# time echo "blah" | cat
blah

real0m0.197s
user0m0.045s
sys 0m0.124s
bash-4.1# time echo "blah" | cat
blah

Yeah I do know that cygwin is usually significantly slower, that's why I 
recompiled openocd with mingw from linux, to ensure that there was no 
cygwin getting in the way, but it made no difference.


The idea behind the bash commands was seeing that simply adding a pipe 
into the command was adding a ~ 100ms delay difference between the user 
and real figures. I thought that'd be relevant by comparison to openocd 
piped commands. This made me think it's a system wide issue, but I 
thought the cygwin guys might have more of an idea about it as they'd be 
using pipes far more often to know if it's fixable. I haven't had a 
chance to start searching their archives yet, just got back into work now.


Thanks for showing that you get similarly slow pipe'd commands. I don't 
suppose you've tried openocd with pipe usage at all to see if it's also 
slow?


Cheers,
Andrew

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Slow pipe usage (was eclipse indigo)

[Andrew Leech]

On 1/07/2011 8:47 PM, Spencer Oliver wrote:

On 1 July 2011 00:41, Andrew Leech  wrote:

Only problem is, it's incredibly slow, unusably slow. A single step can take
5 seconds, where on a normal tcp connection with same configs feels close to
instant, so maybe about 1/4 of a second. Did your windows one behave better?
If so, do you know what version/release of gdb you used?

used Sourcery G++ Lite 2011.03-42
Have not noticed any speed issues, most of my testing was under linux however.
I am running winxp, that has always proved fairly nippy compared to
vista anyway.



Thanks, I was on 2010q3. Tried the newer one, and it initially didn't 
work, just locked up like yagarto. I eventually found reducing the 
jtag_nsrst_delay and jtag_ntrst_delay in my config and that got the 
newer Sourcery going (although this doesn't get yagarto going, it still 
doesn't work for me).


Stepping is still slow though. I'm wondering if this is related to my 
cygwin on this machine, I've noticed that configure scripts on anything 
run incredibly slowly, never found out why. I decided to cross compile 
openocd from linux to rule out any issues from compiling with my cygwin 
(even though I used the mno-cygwin flag) but this also didn't make any 
difference. I'm not sure, maybe cygwin is stuffing up port's still or 
something.


Delving into openocd logs, taking a -d3 on both pipe and tcp usage, I 
get exactly the same commands being run for both when stepping over the 
first line of my program, but in pipe usage lots of them take 100ms longer:


pipe:
Debug:129217869   arm7_9_common.c:2121arm7_9_step():
targetstepped
Debug:129317969gdb_server.c:2200gdb_input_inner():
receivedpacket:'g'
Debug:129418078gdb_server.c:2200gdb_input_inner():
receivedpacket:'s'
Debug:129518078target.c:1063
target_call_event_callbacks():targetevent7(gdb-start)


tcp:
Debug:1161363470arm7_9_common.c:2121
arm7_9_step():targetstepped
Debug:1162363470gdb_server.c:2200
gdb_input_inner():receivedpacket:'g'
Debug:1163363481gdb_server.c:2200
gdb_input_inner():receivedpacket:'s'
Debug:1164363491target.c:1063
target_call_event_callbacks():targetevent7(gdb-start)


notice the time counter increments 100 ms after both the arm7... line 
and the first received packet, whereas for tcp usage there's increments 
of 0 and 1 ms.


There's heaps of commands in the pipe usage that have this extra 100ms 
delay in them:
  Debug:136418111target.c:1063
target_call_event_callbacks():targetevent8(gdb-end)
  Debug:136518111arm7_9_common.c:2121   
 arm7_9_step():targetstepped
here->   Debug:136618211gdb_server.c:2200   
 gdb_input_inner():receivedpacket:'g'
here->   Debug:136718318gdb_server.c:2200   
 gdb_input_inner():receivedpacket:"'m1102941c,4'"
  Debug:136818318gdb_server.c:1278   
 gdb_read_memory_packet():addr:"0x1102941c,"len:0x0004
  Debug:136918318target.c:1444   
 target_read_buffer():readingbufferof4byteat   
 0x1102941c
  Debug:137018318arm7_9_common.c:2270   
 arm7_9_read_memory():address:"0x1102941c,"size:   
 "0x0004,"count:0x0001
here->   Debug:137118419gdb_server.c:2200   
 gdb_input_inner():receivedpacket:"'m110294ac,4'"


after most, but not all arm7_9_read_memory commands, here one that didn't:

Debug:129718078gdb_server.c:1475
gdb_step_continue_packet():step
Debug:122517838arm7_9_common.c:2270
arm7_9_read_memory():address:"0x110294a4,"size:
"0x0004,"count:0x0001
Debug:122617839target.c:1606target_read_u32():
address:"0x110294a4,"value:0xe3a01004
Debug:122717839arm7_9_common.c:1615
arm7_9_restore_context():-
Debug:122817849arm7_9_common.c:1638   
 arm7_9_restore_context():examiningSupervisormode


As far as I can tell, every arm7_9_read_memory() call after a 
target_read_buffer() has the 100ms delay (it's always between 100 and 
103ms) added to it, and there's plenty of them. I'm guessing that's when 
openocd is transferring the read data back up the pipe?


This might be a far too obscure issue to find, and I don't have another 
computer to try it on at the moment to find out if it's something 
specific to my particular pc, or a broader issue. For what 

Re: [Openocd-development] eclipse indigo (pipe usage)

[Andrew Leech]

On 30/06/2011 6:13 PM, Spencer Oliver wrote:

On 30 June 2011 07:47, Andrew Leech  wrote:

Have you used it successfully? Helios has that too (since early 2011?), but
I've never got it running. I've just updated to indigo and still can't make
it work.

I ran a few tests yesterday and it worked fine.
ubuntu was easier to setup than windoze, but both worked.

The gdb connect line used was | openocd as --pipe is now deprecated.
Try putting all the options in openocd.cfg - gdb_port pipe first. When
we switch to using pipes then openocd will automatically use
openocd.log

Cheers
Spen
Thanks for that Spen, great to know it can work. I had already tried 
with gdb_port pipe instread after seeing hte deprecation notice in the 
log, although it didn't make any difference. I also hadn't tried moving 
all those config's into the openocd.cfg file, and yeah it makes it a 
little neater, but didn't fix it, I still had it hanging at the same 
point. I haven't been getting a log file though that I can find in pipe 
mode without explicitly setting one.


Had a random thought, and tried it with sourcery-g++-lite's gdb rather 
than my usual yagarto gdb, and all of a sudden it worked! So there's 
something different/wrong with the yagarto gdb in pipe usage, haven't 
exported full debug logs for both gdb's yet to see where the problem is 
though.


Only problem is, it's incredibly slow, unusably slow. A single step can 
take 5 seconds, where on a normal tcp connection with same configs feels 
close to instant, so maybe about 1/4 of a second. Did your windows one 
behave better? If so, do you know what version/release of gdb you used?


One other point, do you know whether you can get openocd to add it's own 
program directory to the search path for the source [find ...] lines? 
It'd be great to only need the openocd.cfg file in the eclipse project 
dir, and have it reference the interface and target files from the 
common openocd folder. Otherwise I'll likely copy the contents of the 
files into my openocd.cfg rather than have a copy of target and 
interface folders in all my project folders.


I hope I can get pipe working, I've wanted to use this for ages, just 
makes the toolchain feel a lot more professional.


Cheers,
Andrew


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] eclipse indigo

[Andrew Leech]

The downloads for eclipse are always at 
http://www.eclipse.org/downloads/ although if you're on linux, you may 
have it in your package management system... although they've often been 
modified and/or held at older versions.


Andrew

On 1/07/2011 12:53 AM, Michel JAOUEN wrote:

Hello,
I am interested in the indigo latest version.
Can you provide a link to download this latest version .
Thank you in advance
Best regards


-Original Message-
From: openocd-development-boun...@lists.berlios.de 
[mailto:openocd-development-boun...@lists.berlios.de] On Behalf Of Spencer 
Oliver
Sent: Thursday, June 30, 2011 10:13 AM
To: Andrew Leech
Cc: openocd-development@lists.berlios.de
Subject: Re: [Openocd-development] eclipse indigo

On 30 June 2011 07:47, Andrew Leech  wrote:

Have you used it successfully? Helios has that too (since early 2011?), but
I've never got it running. I've just updated to indigo and still can't make
it work.


I ran a few tests yesterday and it worked fine.
ubuntu was easier to setup than windoze, but both worked.

The gdb connect line used was | openocd as --pipe is now deprecated.
Try putting all the options in openocd.cfg - gdb_port pipe first. When
we switch to using pipes then openocd will automatically use
openocd.log

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] eclipse indigo

[Andrew Leech]

Have you used it successfully? Helios has that too (since early 2011?), 
but I've never got it running. I've just updated to indigo and still 
can't make it work.


When trying to start a debug session, it eventually just hangs in the 
openocd startup process after it's detected my device, regardless of 
whether I'm using DSF or standard, both give the same issue.
Openocd starts up, finds my adapter and tap's all correctly, but never 
gets to the stage of loading my application, the last lines are:


Debug: 287 4090 pld.c:232 handle_pld_init_command(): Initializing PLDs...
Debug: 288 4091 command.c:156 script_debug(): command - ocd_command 
ocd_command type ocd_gdb_port pipe
Debug: 289 4091 command.c:156 script_debug(): command - gdb_port 
ocd_gdb_port pipe
Debug: 291 4092 command.c:156 script_debug(): command - ocd_command 
ocd_command type ocd_init

Debug: 292 4092 command.c:156 script_debug(): command - init ocd_init

...and sits there forever.

I've attached the gdb and openocd logs (in -d3 mode) if anyone's got any 
ideas?


To be clear, the same openocd scripts and gdb settings work fine in tcp 
mode, it's just pipe that doesn't work.


Cheers,
Andew

On 29/06/2011 8:25 PM, Spencer Oliver wrote:

I see the latest "GDB Hardware Debugging" plugin in eclipse indigo has
native support for openocd :)

Cheers
Spen
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development


Debug: 18 1995 configuration.c:45 add_script_search_dir(): adding 
D:\Medmont\Hardware\Projects\MCAP\Firmware\MedmontMCAPDevelopment\eclipse.indigo\..
Debug: 19 1995 configuration.c:45 add_script_search_dir(): adding 
D:/Medmont/Hardware/Projects/MCAP/Firmware/MedmontMCAPDevelopment/eclipse.indigo/../share/openocd/scripts
Debug: 20 1995 configuration.c:87 find_file(): found openocd.cfg
Debug: 21 1996 configuration.c:87 find_file(): found 
openocd/interface/jtagkey.cfg
Debug: 22 1996 command.c:156 script_debug(): command - ocd_command ocd_command 
type ocd_interface ft2232
Debug: 23 1996 command.c:156 script_debug(): command - interface ocd_interface 
ft2232
Debug: 25 1996 command.c:373 register_command_handler(): registering 
'ocd_ft2232_device_desc'...
Debug: 26 1996 command.c:373 register_command_handler(): registering 
'ocd_ft2232_serial'...
Debug: 27 1996 command.c:373 register_command_handler(): registering 
'ocd_ft2232_layout'...
Debug: 28 1997 command.c:373 register_command_handler(): registering 
'ocd_ft2232_vid_pid'...
Debug: 29 1997 command.c:373 register_command_handler(): registering 
'ocd_ft2232_latency'...
Info : 30 1997 transport.c:123 allow_transports(): only one transport option; 
autoselect 'jtag'
Debug: 31 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag_flush_queue_sleep'...
Debug: 32 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag_rclk'...
Debug: 33 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag_ntrst_delay'...
Debug: 34 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag_ntrst_assert_width'...
Debug: 35 1997 command.c:373 register_command_handler(): registering 
'ocd_scan_chain'...
Debug: 36 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag_reset'...
Debug: 37 1997 command.c:373 register_command_handler(): registering 
'ocd_runtest'...
Debug: 38 1997 command.c:373 register_command_handler(): registering 
'ocd_irscan'...
Debug: 39 1997 command.c:373 register_command_handler(): registering 
'ocd_verify_ircapture'...
Debug: 40 1997 command.c:373 register_command_handler(): registering 
'ocd_verify_jtag'...
Debug: 41 1997 command.c:373 register_command_handler(): registering 
'ocd_tms_sequence'...
Debug: 42 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 43 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 44 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 45 1997 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 46 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 47 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 48 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 49 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 50 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 51 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 52 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 53 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 54 1998 command.c:373 register_command_handler(): registering 
'ocd_jtag'...
Debug: 55 1998 command.c:373 register_command_handler(): registering 
'ocd_svf'...
Debug: 56 1998 command.c:373 register_command_han

Re: [Openocd-development] [Patch] increase buffer size for svf files

[Andrew Leech]

On Mon, Mar 28, 2011 at 8:28 AM, Øyvind Harboe  wrote:
> I tried this with a big enough buffer on a real device and it
> segfaulted.
>

Wasn't most/all of the required code for dynamic buffer resizing
already present in the code but commented out with #if 0 #else #end
lines? It sounds like this might be a better avenue then just raising
the static buffers more and more although this isn't necessarily
likely to help with the crashing issue.
Last time this issue came up I had a look a the code, but didn't get a
chance to try it out.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Integrating a JTAG interface adapter

[Andrew Leech]

On Tue, Mar 8, 2011 at 12:54 AM, Jean-Claude Repetto  wrote:
> Hello,
> I am currently designing a custom development board for a system based on an
> EFM32 ARM-Cortex M3 device.
> I would like to integrate a JTAG adapter on this board, so that software
> developers don't need to buy an external adapter.
>
> So, I am looking for a solution that can work with OpenOCD on both
> Linux and Windows platforms, in SWD mode. Maybe some people on this list
> have already solved this problem, could there share their solutions ?
>
> Thanks,
> Jean-Claude

Unfortunately SWD support is not quite available in openocd yet,
although it is being worked on (by others, not myself - I've got no
claim to fame here). If you check the archives you'll see quite a bit
of discussion on SWD recently, including a report from Tomek from a
couple of days ago that he's just got a connection with SWD using
urjtag rather than openocd, using code he's writing, which will be
brought over to openocd more than likely once finished.

As far as adding hardware to a board, this is pretty straightforward.
Easiest solution is to use a FT2232 / FT2232H and pick a common layout
using it as a jtag programmer, and just put it on the same board. If
you want full compatability you should be able to wire it up to handle
both SWD and jtag (if you've got jtag pins), that way it'll work right
now as jtag, and hopefully as SWD in future. I've done this in the
past using the schematic for the luminary/ti ICDI which has hardware
support for both jtag swd, although Tomek used kt-link, so you could
try copying the ft2232h pinout from that if you want the best chance
of compatibility. The ti/luminary one at least has full schematics,
just grab the user manual pdf for DK-LM3S9B96-UM-04 and it has the
icdi schematics on the last two pages of schematics (google gives the
link).

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] SVF echo does not show SDR commands

[Andrew Leech]

On Tue, Mar 1, 2011 at 7:39 AM, Phil Fong  wrote:
> I've been programming Lattice XP2 FPGAs with SVF using a git checkout from 
> the beginning of February.  (So, to answer Oyvind svf at least partially 
> works.)  However, I've noticed that the echo to the screen does not echo the 
> first line of SDR commands.  The SVF has SDR commands of the form:
> SDR    638    TDI  
> (3FFFFFFEEEFFFFFF
>             
> FFFFFFFFEE6EFFFF);
>
> The output in the telnet session and the OpenOCD console only shows the 
> second line.  If SDR command is only one line, nothing is shown.
>
> Is this intentional?
>

Ah, this'll probably be my fault, and it's not intentional must be
something I missed when I modified the verbose stuff late last year.
I've only been using the svf command to program my actel fpga with an
auto-generated svf file, and haven't noticed this issue, either
because I don't get multiline commands in the generated file, or
because they flick past the screen so fast I don't notice them!

Do you now whether the command are being run correctly? I assume
because you haven't said otherwise then they must be, just not getting
printed.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Error and then segfault with svf

[Andrew Leech]

On Tue, Mar 1, 2011 at 6:04 AM, Øyvind Harboe  wrote:
>
>
> On Mon, Feb 28, 2011 at 7:40 PM, Andrew Leech 
> wrote:
>>
>> On 28/02/2011 7:01 PM, Øyvind Harboe wrote:
>>>
>>> Has anyone used the SVF support recently?
>>>
>>> I've tried to use svf, but it doesn't work in my case.
>>>
>>> I've attached a test file + I've modified OpenOCD so
>>> it is possible to reproduce this problem without any
>>> interface or target hardware.
>>>
>>> ./configure --enable-maintainer-mode --enable-dummy
>>> make -s
>>> sudo make install
>>>
>>>
>>> openocd -c "interface dummy" -c init -c "svf nil test.svf"
>>>
>>> ...
>>> Error: buffer is not enough, report to author
>>> Error: fail to run command at line 2513
>>> Error: tdo check error at line 33
>>> Error: read = 0x0, want = 0xF2618093, mask = 0xFFF
>>>



>
> It shouldn't be hard to track down, especially as it can be
> reproduced without target or interface hardware, ref.
> my previous post.
>

Ok, just checked the code. The issue is coming from code I've never
dealt with before, but it's stemming from a very long line in the svf
like I suspected it might be, a SDR command starting on line 81 of the
svf. The code has/had buffer reallocation code to handle large lines
like this, but it's been commented out ( via #if 1 \ #else \ #endif )
on line 1207 of svf.c
There's a similar mod been made to the code at 1302 on the SIR command.

I don't really have time to reinstate the buffer resizing code and
check it right now, and I've got no idea who/why it was originally
taken out of use.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Error and then segfault with svf

[Andrew Leech]

On 28/02/2011 7:01 PM, Øyvind Harboe wrote:

Has anyone used the SVF support recently?

I've tried to use svf, but it doesn't work in my case.

I've attached a test file + I've modified OpenOCD so
it is possible to reproduce this problem without any
interface or target hardware.

./configure --enable-maintainer-mode --enable-dummy
make -s
sudo make install


openocd -c "interface dummy" -c init -c "svf nil test.svf"

...
Error: buffer is not enough, report to author
Error: fail to run command at line 2513
Error: tdo check error at line 33
Error: read = 0x0, want = 0xF2618093, mask = 0xFFF

Hi, as it turns out I updated/compiled my git just yesterday (from 
mainline), after which I programmed my Actel PA3 a couple of times via 
svf. it worked perfectly fine for me with that.
I don't have the source with me at the moment but "Error: buffer is not 
enough, report to author" sounds familiar, I think the main buffer that 
each line gets read into is static - do you have any very long single 
lines? Either that or for some reason the line detection in the code 
isn't working. Or I'm remembering the error wrong. either way sounds 
like it should be easy enough to track down.


Andrew

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] gdb startup from eclipse failue

[Andrew Leech]

On Tue, Feb 15, 2011 at 7:56 AM, Bernard Mentink  wrote:
> Hi Guys,
> Andrew, yes, I have checked all the settings in the Debug Configuration
> settings and they all point to the correct files, and I have the correct
> file in my load command, but gdb is crashing even before it connects to
> openocd.
> I also cannot find the "verbose console mode"  checkbox in the debugger tab
> in Debug configurations dialog, do you have a different version? I am
> running eclipse version: Version: Helios Release Build id: 20100617-1415
> And openocd is Open On-Chip Debugger 0.5.0-dev  version ..

I'm running:
Version: Helios Service Release 1
Build id: 20100917-0705

I highly suggest you update it, when I first tried the original Helios
it was so incredibly buggy I switched back to the previous release
until this update came out.
Also, are you using the GDB hardware debugging module to talk to
openocd (part of CDT) with it? (aka not something else like older
zylin... don't know if it's even possible with helios)
I'm using it in standard GDB Hardware Debugging Launcher mode (down
the bottom of the Debug Configurations window), not in DSF mode (I
assume you'll only get this choice if you've installed DSF stuff from
CDT as well). The verbose checkbox may have come with SR1, or with
this mode, I'm not entirely sure. Chances are it's a SR1 thing though.

> Øyvind, the command line doesn't crash  so not sure what eclipse/gdb is
> doing.
> It seems my executable is the problem, because when I replace the "good"
> project elf file with the "bad" project elf, the good project fails as well
> ...
> To duplicate the project, I just did a copy/paste within the eclipse IDE and
> everything built ok  really confused why this object file crashes the
> debugger ..

With copying projects, I've done this a number of times myself - often
I forget to change the build directory in the project settings, and
while it looks like it's compiling fine, it's actually compiling the
old project still because it's pointing to that folder.
These days in the Project settings -> C/C++ Build -> Builder settings
I set the Build Directory to ${ProjDirPath} which removes this
problem. This is for a makefile based system, which I assume you're
using.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] gdb startup from eclipse failue

[Andrew Leech]

On Mon, Feb 14, 2011 at 12:48 PM, Bernard Mentink  wrote:
> Hi All,
> I apologize for posting a somewhat openocd off-topic question, but I am in a
> bind.
> I have been using openocd and gdb from within eclipse quite happily, until I
> duplicated a project to start a new one, and tried debugging it.
> When gdb launches from within eclipse, I get a windoze crash dialog box,
> then the following error:
> "Error in final launch sequence
> Connection is shut down"
> However if I launch gdb from the old project it is fine. The debug settings
> between projects are identical  apart from the object code ..
> If I copy the "good" object code into the new project location ... I still
> get the error, so doesn't look like the object code is the issue ..
> Anyone offer any suggestions?

The only thing that comes to mind is checking to be sure that the
debug configuration settings are all referencing the new files in the
new project. On the main tab of debug configurations ensure the new
project is selected, and that the c/c++ application is set to the new
object file. Then on the startup tab that the image and symbols are
either set manually to the new one or to project binary (which has
just been checked).

And/or, if your object file is loaded with openocd (I load mine
through gdb) check that your openocd script is pointing to the new
object/bin file.

> I don't know how to get more info from gdb as to what is going on ..

Depends on whether the problem is arising from gdb or openocd. openocd
script can be changed to add --debug <0-3> to its command line.
For GDP I've got a "verbose console mode" checkbox on the Debugger tab
of debug configurations (just under the popup of protocol version)
that when enabled gives a heap of extra console output.

For reference I'm using Eclipse helios sr1 with GDB Hardware
Debugging, yagarto for gcc/gdb and git trunk openocd.

I know  what you mean about this being somewhat off topic, but I feel
your pain, there doesn't seem to be a particularly good place to
discuss issues relating to the overall open source toolchain setup.
Similarly I've got serious issues getting pipe openocd working
properly in helios. It'd be great to have running, but in the rare
configurations it actually connects to the target correctly, it debugs
(ie step, read regs, etc) at such an abysmally slow pace it's
unusable, whereas the traditional method of external tool openocd and
sockets works fine. This in on windows too, so it's quite possibly
just that pipes on windows are a bit of a hack? Either way I've given
up on pipe for now.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time

[Andrew Leech]

On Mon, Jan 10, 2011 at 2:59 PM, Andrew Leech  wrote:
> On Mon, Jan 10, 2011 at 1:20 PM, Jon Povey  wrote:
>> Andrew Leech wrote:
>>> On 06/01/2011, at 3:12 PM, Jon Povey wrote:
>>
>>>> Ping.
>>>
>>> I never delved much into the actual SVF commands, so can't
>>> comment on the basic logic of it, however if the new
>>> functionality is correct the old stuff blocked out by #if 1/0
>>> should be removed before committing upstream as it's just dead code
>>> and messy.
>>
>> I didn't know why that was in there. If someone knows it should be removed I 
>> think that should be a separate patch.
>>
>>> Unfortunately I can't check that your updated version works
>>> on my (actel) hardware for at least another week or so at
>>> this rate, but if the logic's right I can't see why it wouldn't be
>>> fine.
>>
>> OK, just trying not to let it get forgotten.
>> Can you think of anyone else I should look for an ACK from before getting 
>> Oyvind to pull his itchy merge trigger finger? :)
>>
>
> Ah, I assumed it was part of your changes. In that case it would be
> another patch, not for this one.
> I don't know if there's anyone else around to chime in, when I was
> adding my stuff a couple of months ago there wan't many other
> commentators, Peter Stuge gave a lot of assistance but it was more to
> do with good coding style and logical layout rather than the actual
> svf handling. SVF really is a rarely touched module from what I can
> tell.
>


For what its worth I just reprogrammed my actel FPGA just fine with
your svf_implement_sleep_for_RUNTEST_min_time patch compiled in, so
you've got no complaints from me.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time

[Andrew Leech]

On Mon, Jan 10, 2011 at 1:20 PM, Jon Povey  wrote:
> Andrew Leech wrote:
>> On 06/01/2011, at 3:12 PM, Jon Povey wrote:
>
>>> Ping.
>>
>> I never delved much into the actual SVF commands, so can't
>> comment on the basic logic of it, however if the new
>> functionality is correct the old stuff blocked out by #if 1/0
>> should be removed before committing upstream as it's just dead code
>> and messy.
>
> I didn't know why that was in there. If someone knows it should be removed I 
> think that should be a separate patch.
>
>> Unfortunately I can't check that your updated version works
>> on my (actel) hardware for at least another week or so at
>> this rate, but if the logic's right I can't see why it wouldn't be
>> fine.
>
> OK, just trying not to let it get forgotten.
> Can you think of anyone else I should look for an ACK from before getting 
> Oyvind to pull his itchy merge trigger finger? :)
>

Ah, I assumed it was part of your changes. In that case it would be
another patch, not for this one.
I don't know if there's anyone else around to chime in, when I was
adding my stuff a couple of months ago there wan't many other
commentators, Peter Stuge gave a lot of assistance but it was more to
do with good coding style and logical layout rather than the actual
svf handling. SVF really is a rarely touched module from what I can
tell.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Cable madness

[Andrew Leech]

On Mon, Jan 10, 2011 at 1:25 PM, Jon Povey  wrote:
> openocd-development-boun...@lists.berlios.de wrote:
>> They didn't have any 0.05" pre-crimped solutions that I could
>> find.
>
> Crimping your own is not hard with something solid to push down with (bit of 
> wood or such).
>
>> It seems like everybody is doing something different Throw in
>> that a lot of application PCBs don't have anything resembling a normal
>> JTAG 0.1" or 0.05" connector and then you're off to the hw engineer
>> on the project to have him put something together...
>
> imo basic soldering / electrical skills are part of being an embedded 
> engineer, if you want to play around trying to fit square pegs in round holes.
>
> To abuse a famous quote; give a man a vendor cable and he can program one 
> board. Teach him to fabricate his own cables..
>

Hah, I am the hw engineer (as well) and I crimp most of my cables with
my trusty long nose pliers. I don't have much in the way of fancy
crimping tools, but haven't ever really needed them (they do a nice
job though when you can get them). I must say though if I want my
cables to last a little longer I'll but a dab of solder in the crimp
as well.

On a more useful front, for 0.1" pitch connectors, the most flexible
option is individual labelled pins on each line, like what altium have
done with their breakout cable:
http://www.altium.com/community/newsletters/february-09/en/jtag_adapter.cfm
If you need to plug/unplug it a fair bit just tape the pins together
in the right shape, then pull the tape off for the next layout.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH 2/2] svf: implement sleep for RUNTEST min_time

[Andrew Leech]

On 06/01/2011, at 3:12 PM, Jon Povey wrote:

> Jon Povey wrote:
>> Signed-off-by: Jon Povey 
>> 
>> min_time was effectively ignored, I needed it to program a
>> Lattice MachXO
>> which uses a RUNTEST to wait for an erase operation, amongst
>> other things.
>> 
>> With this patch pauses happen and I can program the device with an SVF
>> generated in LSC ispVM (with "Rev D Standard" checked to suppress
>> nonstandard LOOP statements) ---
>> 
>> src/svf/svf.c |   58
>> +++-
>> 1 files changed, 28 insertions(+), 30 deletions(-)
> 
> Ping.

I never delved much into the actual SVF commands, so can't comment on the basic 
logic of it, however if the new functionality is correct the old stuff blocked 
out by #if 1/0 should be removed before committing upstream as it's just dead 
code and messy.
Unfortunately I can't check that your updated version works on my (actel) 
hardware for at least another week or so at this rate, but if the logic's right 
I can't see why it wouldn't be fine.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] SVF chain handling patch

[Andrew Leech]

On Sun, Dec 5, 2010 at 11:19 PM, Øyvind Harboe  wrote:
>> I'm happy with the previous set of patches I submitted (nov 30),
>> it's been working well for me for the past couple of weeks
>> with no issues.
>
> I had to make some fixes to make it compile.
>
> Could you read over the patch now and write up a commit comment?
>
> To create a patch, try:
>
> git add .
> git commit --author="Andrew Leech "
> => type commit comment
> git format-patch HEAD^

Could you let me know what your platform / configure options are that
it didn't compile originally? I'd like to test them myself in future
to find any issues myself before making patches. Otherwise yeah the
only changes in your version of the patch compared to my tree with all
4 of my ones merged are the couple of ints changed to size_t, although
one of the lines changed a number of variables (cmd_ok, slash,
comment), not all of which should be I think, so I split the line.

Are you happy for all this to be in one patch/commit? I just thought
perhaps it should be split up to make it easier to find an issue if
one is uncovered later. Otherwise I've attached a hopefully properly
formatted patch as above.

Cheers,
Andrew


0001-added-support-for-targeting-particular-tap.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] (patch) Change target script for LPC2478

[Andrew Leech]

On 05/12/2010, at 7:49 PM, Freddie Chopin  wrote:

> On 2010-12-04 19:29, Michael Schwingen wrote:
>> Just because the current files are hard-wired in a way that suits you
>> does not mean they work fine for everyone.
> 
> Have you considered opposite approach? Just because the need of creating 
> another file suits you does not mean this is fine for everyone.
> 
Just to throw in a suggestion, would it simply be better to have a hardwired 
default that can be overridden in the config file?

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On 04/12/2010, at 7:43 PM, Øyvind Harboe  wrote:

> How's this one coming?
> 
> 
I'm happy with the previous set of patches I submitted (nov 30), it's been 
working well for me for the past couple of weeks with no issues. 

Andrew
> 

___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Wed, Nov 24, 2010 at 12:10 AM, Wookey  wrote:
> +++ Andrew Leech [2010-11-17 14:02 +1100]:
>>
>> Yep I rewrote the command line parser, so the usage is now:
>> "usage: svf [-tap device.tap] [-quiet] "
>>
>> Arguments are checked in a loop so it will accept switches and 
>> in any order. quiet or -quiet are both recognised. And of course, -tap
>> is optional. As such it is now back compatible, much nicer and more
>> flexible. There's also a help switch that simply prints usage in case
>> anyone tries it.
>
> As someone who has previously used svf and xsvf functionality with
> chained devices I'd like to add another 'yes please this is great'
> vote, and thank andrew for his work (I'm glad someone understands
> this stuff :-)
>
> Oddly I have previously found that xsvf files would work even when
> they were generated single but used in a chain (or maybe it was the
> other way round). I was quite suprised about this and assumed that
> openocd was already doing something clever equivalent to the
> functionality this patch provides. But obviously that was just dumb
> luck.
>
> And yes the above syntax is the right way tto do this. Breaking
> existing scripts is something we should work hard to avoid as it can
> make openocd updates in production environments very awkward..
>
> Wookey

Yeah I'm much happier allowing previous syntax to work fine without
modification. I haven't looked at the xsvf module at all, while it
would be neater to bring it in line with this one, or even roll both
of them rolled together, I don't have any xilinx parts or software so
haven't had any call to use it. The xsvf parser or format may very
well have chain functionality built into it, I'm not sure.

Well I've made a whole heap more updates, and eventually realised I
should be splitting them up into separate patches, as many of them are
(or should be) somewhat independent. That was a bit of a hassle, but
it's neater this way as well as being openocd policy from what
I've read.

svf_chain_cmd_parser.patch : Main patch, chain tap handling and
updated command parser, mostly the same as earlier submitted patch.
svf_file_handling.patch: converts file handling from open to fopen
etc. Also input files are read as whole lines before parsing.
Debatable whether this is neater code, but it does result in 10% speed
improvement for me, and should be more portable.
svf_progress_indicator.patch: Adds progress indicator (xx% readout)
when (-)progress flag added to command line. this works in both quiet
and non-quiet modes. This patch is dependent on
svf_file_handling.patch being previously applied.
svf_time_output_format.patch: time taken readout at end of svf
operation converted from direct ms output to minutes-seconds-ms output
for better readability.

I've used this newer version to program my a3p125 and a3p060 parts on
identical chains with lpc3131 multiple times with different flags and
haven't had any problems.

One significant finding is the time difference when non-quiet
(default) mode is used, particularly on windows the verbose output
slows the overall operation down a _lot_. I'm talking 1mins 19sec for
quiet compared to 6mins 40sec on verbose. The time difference on linux
was much much less severe but I haven't tested it with the full length
file, but but on a much shorter test file it was a difference of 8
seconds to 14 seconds. The programming works fine either way, just
printing the lines takes some time. This slow file is ~290,000 lines
of svf, so not surprising that it takes some time to print all this to
console.

Andrew


svf_chain_cmd_parser.patch
Description: Binary data


svf_file_handling.patch
Description: Binary data


svf_progress_indicator.patch
Description: Binary data


svf_time_output_format.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Thu, Nov 18, 2010 at 4:43 PM, Peter Stuge  wrote:
> Andrew Leech wrote:
>> > (A note that you can send patches easily by first committing and then
>> > using the git send-email command.)
>>
>> Ok I'm still pretty new to git, so by committing it just adds changes
>> to the local repository not the mainline one?
>
> Exactly. Every git working copy is a fully worthy repository clone.
> (Hence the git clone command.)

Thanks for the git helper, that's a really concise overview of the diff usage.

>
>
>> I'm in no way certain about quiet having a dash, it just seems more
>> consistent to me to have all switches with a dash, more like standard
>> *nix programs. On the other hand it's also important to keep
>> consistency within openocd to try to make it easier to use.
>
> The backwards compatibility is something I think is particularly
> important, even if the SVF support is not the most frequently used
> part of openocd.
>

I agree on the backwards compatibility, hence I made the dash on quiet
optional, it accepts quiet and -quiet. But yeah it does look cleaner
with no dash I feel.

>
>> I'm also not too concerned whether -help stays in there, as as
>> mentioned yes usage gets printed if you have an incorrect command
>> line anyway. I'm not sure if help as a command is common in any
>> other modules. Either way I'm more than happy for you or anyone to
>> modify the command line layout / behavior to keep it relevant.
>> For now I've changed it to usage: svf [-tap device.tap] 
>> [quiet], I do think this looks cleaner.
>
> That's really good. That means that the change has a minimal and
> clean contact surface with everything previous.
>
>
>> >> +static int svf_adjust_array_length(uint8_t **arr, int orig_bit_len, int 
>> >> new_bit_len, int set);
>> >
>> > I would suggest adding a function with a new name that takes the
>> > extra parameter, and renaming the existing function, and adding the
>> > parameter to it. Then add a one-line function with the original name
>> > that calls the new function with the last parameter set to 0. This
>> > way, each previous call site for the existing function does not need
>> > to be touched by this patch. The new call sites invoke the renamed
>> > function and specify values as needed for the extra parameter.
>> >
>>
>> Once again this was the way I was initially implementing it and it
>> gave some minor issues and I then thought it seemed wasteful to add
>> another function just to modify the functionality of an existing
>> function. But yeah, going and modifying all calls to an existing
>> function is pretty messy too.
>
> Adding a function which is basically just a wrapper is admittedly a
> little wasteful, but I think the benefit of keeping the change small
> and clean is important enough to outweigh that waste. Your new
> solution is even better though.
>
>
>> >  command_print(CMD_CTX, "open(\"%s\"): %s", CMD_ARGV[i], strerror(err));
> ..
>> Yeah that error reporting makes a lot of sense, added. Now if you
>> specify a folder rather than a file you get "permission denied", much
>> better.
>
> All right!
>
>
>> I'm testing on Windows 7 (cygwin) x64 (x32 openocd binaries) and
>> haven't had any issues with the file open. I've got a linux vm I
>> could have a got at compiling it on, probably should give it a test.
>
> If you like to, but I don't think it's needed. I was mostly worried
> about how this would behave on Windows, and since you have tested
> there I don't think the changes need more testing.
>
>
>> > Watch out for trailing whitespace, in the last line quoted above.
>>
>> Ah now I see what you mean about the trailing whitespace, I never
>> recognized this before. I think I've fixed it up, haven't noticed any
>> in the new patch.
>
> git diff can colour code it's output, and make whitespace errors very
> visible. The colouring works by default in Linux, but unfortunately
> not in Windows. Maybe this is sufficient:
>
> git config --global color.ui true
> git config --global core.whitespace trailing-space,space-before-tab
>
> Also make sure to let git know that it should not permit any Windows
> line-endings into the codebase:
>
> git config --global core.autocrlf true
>
>



>> -     if ((svf_fd = open(CMD_ARGV[0], O_RDONLY)) < 0)
>> +
>> +     if (svf_fd == NULL)
>
> Sorry, this isn't right. The fd is an int, open() returns < 0 on
> failure, but

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Thu, Nov 18, 2010 at 2:29 AM, Peter Stuge  wrote:
> Andrew Leech wrote:

>>
>> I'll look into that, I've not used snprintf so don't really know the
>> difference. It's obviously only a google away. I'm just used to
>> sprintf from embedded devices when you often don't have a choice of
>> using a better alternative (depending on compiler).
>
> The point of snprintf() is that it will never write beyond the given
> buffer size, yet always terminate the string with a \0. The return
> value can be used to check if the buffer was large enough. This works
> together to avoid possible buffer overrun conditions, which are quite
> frequently exploited to inject code via data, and break security of
> the program or product.
>

Thanks, that's good to know, and makes a lot of sense.

>> Note newer patch attached. This is made directly against current
>> git, use instead of original patch.
>
> (A note that you can send patches easily by first committing and then
> using the git send-email command.)
>

Ok I'm still pretty new to git, so by committing it just adds changes
to the local repository not the mainline one? So far I'm just doing a
git diff > blah.patch


> Good stuff! I just have one very minor request for the help text:
>
> usage: svf [[-]help] [-tap device.tap]  [[-]quiet]
>
> If [-]help is common in other commands then it is good to have here,
> but otherwise I think it might be redundant. If I just enter svf
> (without further options) then I will get the same output, right?

yep

>
> Also, I'd like quiet to still be at the end, to signal a little more
> that this is still backwards compatible.
>
> Are you sure about the dash in -quiet?
>
> I would feel best about this:
>
> usage: svf [-tap device.tap]  [quiet]
>
> Because quiet can be treated specially, and it is even possible to
> reliably allow a -tap filename by careful evaluation of the
> arguments. I would be happy to make this change if you're OK with
> that.
>

I'm in no way certain about quiet having a dash, it just seems more
consistent to me to have all switches with a dash, more like standard
*nix programs. On the other hand it's also important to keep
consistency within openocd to try to make it easier to use. I'm also
not too concerned whether -help stays in there, as as mentioned yes
usage gets printed if you have an incorrect command line anyway. I'm
not sure if help as a command is common in any other modules. Either
way I'm more than happy for you or anyone to modify the command line
layout / behavior to keep it relevant.
For now I've changed it to usage: svf [-tap device.tap] 
[quiet], I do think this looks cleaner.

>
>> >> reuse .. existing handling of head/tail
> ..
>> I dug deep enough to figure out how it works, it uses array's that it
>> dynamically sets the size of, so it's a little convoluted to set them.
>
> I'd like to suggest a function to handle the setting, see below.
>
>
>> It's debatable whether this newer code is neater to understand, but
>> it is certainly far more efficient to run, and avoids all the extra
>> string handling.
>
> I like the new approach very much!
>
>
>> Other than that it seems to run fine, I've tested the command line in
>> pretty much every direction and it works well. The operation of
>> header/trailer padding certainly seems to be completely compatible
>> with my first effort, I don't think I've missed anything of left out
>> any important steps.
>
> Lovely.
>
>
>> +static int svf_adjust_array_length(uint8_t **arr, int orig_bit_len, int 
>> new_bit_len, int set);
>
> I would suggest adding a function with a new name that takes the
> extra parameter, and renaming the existing function, and adding the
> parameter to it. Then add a one-line function with the original name
> that calls the new function with the last parameter set to 0. This
> way, each previous call site for the existing function does not need
> to be touched by this patch. The new call sites invoke the renamed
> function and specify values as needed for the extra parameter.
>

Once again this was the way I was initially implementing it and it
gave some minor issues and I then thought it seemed wasteful to add
another function just to modify the functionality of an existing
function. But yeah, going and modifying all calls to an existing
function is pretty messy too.

>
>> +             else if ((svf_fd = open(CMD_ARGV[i], O_RDONLY)) < 0)
>>               {
>> -                     LOG_ERROR("unknown variant for svf: %s", CMD_ARGV[i]);
>> -
>> +                     command

Re: [Openocd-development] Config file format/line endings

[Andrew Leech]

On Wed, Nov 17, 2010 at 8:05 AM, Steve Bennett  wrote:
> On 16/11/2010, at 11:36 AM, Andrew Leech wrote:
>
>> On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett  
>> wrote:
>>>
>>> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote:
>>>
>>>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett  
>>>> wrote:
>>>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
>>>>>
>>>>>> Hi all,
>>>>>> I've just found a compiling/usage difficulty with the git version on
>>>>>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
>>>>>> jimtcl?) openocd no longer handles dos line endings on config files.
>>>>>> Apparently all my config files of my existing 0.4.0 installation have
>>>>>> dos line endings and I'd never realised or cared, but I compiled git
>>>>>> on cygwin and tried to use it with my existing openocd.cfg and was
>>>>>> treated to this error:
>>>>>>



>
> Perhaps you could try the attached patch to Jim Tcl. It should
> allow for cfg files with dos line endings.
>
>
< 0001--source-now-opens-the-script-file-in-text-mode.patch >

This patch works for me, openocd.exe now works with new config files
(unix line endings) and my old ones (dos line endings).

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

Note newer patch attached. This is made directly against current git,
use instead of original patch.

On Wed, Nov 17, 2010 at 10:44 AM, Andrew Leech  wrote:
> On Wed, Nov 17, 2010 at 10:11 AM, Peter Stuge  wrote:
>
>>>  COMMAND_HANDLER(handle_svf_command)
>>>  {
>>> -#define SVF_NUM_OF_OPTIONS                   1
>>> +#define SVF_NUM_OF_OPTIONS                   2
>>
>> Aren't there three?
>>
> Yeah actually I had wondered about this, I simply incremented it
> and didn't come back to check it. It should probably be 3 and fix the
> (1 + SVF_NUM_OF_OPTIONS) below.
>

Fixed.

>>
>>
>> This is somewhat heuristic:y however. Not nice. A more reliable
>> approach might be:
>>
>> usage: svf [-tap device.tap]  [quiet]
>>
>> In particular I would also like to avoid "device#" because the
>> parameter should not be a number at all, rather the dotted tap name.
>> You mentioned that you modelled after xsvf, so that help text should
>> probably also be clarified.
>>
>

Yep I rewrote the command line parser, so the usage is now:
"usage: svf [-tap device.tap] [-quiet] "

Arguments are checked in a loop so it will accept switches and 
in any order. quiet or -quiet are both recognised. And of course, -tap
is optional. As such it is now back compatible, much nicer and more
flexible. There's also a help switch that simply prints usage in case
anyone tries it.

>>
>> Would it make sense to reuse the existing handling of head/tail
>> rather than creating commands to be run? This would remove the
>> need for a command buffer at all, and maybe make the change even
>> smaller.
>>
>
> Yeah I was initially going to do this, it's just that I found the code
> somewhat obfuscated and decided to go the quick and easy to read route
> rather than delving into the code much deeper. Basically it came to
> lazyness which is the ideal way to create code bloat
> But yeah looking at it again now it does seem simpler than when I
> initially looked though the code, amazing how a little familiarity
> goes a long way. Perhaps I will fix it up, I've got a little time at
> the moment and looks like maybe it'll be quite straightforward.
>

I dug deep enough to figure out how it works, it uses array's that it
dynamically sets the size of, so it's a little convoluted to set them.
It's debatable whether this newer code is neater to understand, but it
is certainly far more efficient to run, and avoids all the extra
string handling.

Other than that it seems to run fine, I've tested the command line in
pretty much every direction and it works well. The operation of
header/trailer padding certainly seems to be completely compatible
with my first effort, I don't think I've missed anything of left out
any important steps.

Andrew


svf_chain_2.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Wed, Nov 17, 2010 at 10:11 AM, Peter Stuge  wrote:

>> diff --git a/src/svf/svf.c b/src/svf/svf.c
>> index 62e2324..c7401c3 100644
>> --- a/src/svf/svf.c
>> +++ b/src/svf/svf.c
>> @@ -221,6 +221,8 @@ static uint8_t *svf_tdi_buffer = NULL, *svf_tdo_buffer = 
>> NULL, *svf_mask_buffer
>>  static int svf_buffer_index = 0, svf_buffer_size = 0;
>>  static int svf_quiet = 0;
>>
>> +static int svf_tap_is_specified = 0;
>> +
>>
>>  static void svf_free_xxd_para(struct svf_xxr_para *para)
>>  {
>> @@ -301,43 +303,50 @@ int svf_add_statemove(tap_state_t state_to)
>>
>>  COMMAND_HANDLER(handle_svf_command)
>>  {
>> -#define SVF_NUM_OF_OPTIONS                   1
>> +#define SVF_NUM_OF_OPTIONS                   2
>
> Aren't there three?
>
Yeah actually I had wondered about this, I simply incremented it
and didn't come back to check it. It should probably be 3 and fix the
(1 + SVF_NUM_OF_OPTIONS) below.

>
>>       int command_num = 0;
>>       int ret = ERROR_OK;
>>       long long time_ago;
>>
>> -     if ((CMD_ARGC < 1) || (CMD_ARGC > (1 + SVF_NUM_OF_OPTIONS)))
>> +     /* use NULL to indicate a "plain" xsvf file which accounts for
>> +        additional devices in the scan chain, otherwise the device
>> +        that should be affected
>> +     */
>> +     struct jtag_tap *tap = NULL;
>> +
>> +     if ((CMD_ARGC < 2) || (CMD_ARGC > (1 + SVF_NUM_OF_OPTIONS)))
>>       {
>> -             command_print(CMD_CTX, "usage: svf  [quiet]");
>> +             command_print(CMD_CTX, "usage: svf   
>> [quiet]");
>
> Maybe we can find a better syntax for the command. Alternatively, I
> think it can be made backwards compatible.
>
> If jtag_tap_by_string() fails for the first parameter
>  If there are only two parameters
>    Assume that the first parameter is the filename
>
> This is somewhat heuristic:y however. Not nice. A more reliable
> approach might be:
>
> usage: svf [-tap device.tap]  [quiet]
>
> In particular I would also like to avoid "device#" because the
> parameter should not be a number at all, rather the dotted tap name.
> You mentioned that you modelled after xsvf, so that help text should
> probably also be clarified.
>

Yeah I thought the "device#" probably isn't the right name, the
command does accept the dotted name so the terminology should be
fixed. I tend to agree with you on the [-tap xxx ] idea, it is much
cleaner. I guess there's nothing special about the xsvf modules
handling, if anything it should probably be updated to support a -tap
command instead as well, and maybe quiet should be changed to -quiet
to be similarly consistent.

>
>> +             if (svf_command_buffer_size < MAX_CHAIN_HEADER_COMMAND_LEN)
>> +             svf_command_buffer = malloc(
>> +                                                     svf_command_buffer_size
>> +                                                     + 
>> MAX_CHAIN_HEADER_COMMAND_LEN);
>
> The indenting seems off in the above. But more importantly I think it
> would be nice to avoid runtime allocation of memory here. The
> commands that this buffer is being used for are short so a char cmd[64]
> should be enough, and makes operation more reliable.

That's interesting, I actually would normally have used a basic static
buffer exactly how you suggest, it's only that the malloc'd
svf_command_buffer is used later for running commands I thought it'd
make sense to reuse it rather than adding a static ram usage to the
module (and therefore openocd).

>
>> +             sprintf(svf_command_buffer, "STATE RESET ");
>> +             svf_run_command(CMD_CTX, svf_command_buffer);
>
> sprintf() is not a friend. :) Yes, the commands are short, but still,
> it would feel better with snprintf(cmd, sizeof(cmd), ..).

I'll look into that, I've not used snprintf so don't really know the
difference. It's obviously only a google away. I'm just used to
sprintf from embedded devices when you often don't have a choice of
using a better alternative (depending on compiler).

>
> These commands without parameters don't even perhaps do not even need
> to be copied into the cmd buffer first, will svf_run_command() take a
> const char[]? Then just do:
>
> svf_run_command(CMD_CTX, "STATE RESET");
>

Yeah I initially had them written as such and they died big time, I'm
not sure how but they resulted in a smiley face character being
printed on console and system beep when they were run through the
command parser, so I went to the longer sprintf route. But it's
probably just a case of fixing the svf_run_command to accept const
chars would be a better option.

>
>> +             sprintf(svf_command_buffer, "RUNTEST IDLE 5 TCK 200E-6 SEC ");
>> +             svf_run_command(CMD_CTX, svf_command_buffer);
>
> Can you reason a little around these particular values?
>
Um... whoops I meant to cut them out, they're not needed anymore. They
were in the initial header from Actel, and are somewhat arbitrary in
that sense.

>
>> +             sprintf(svf_command_buffer, "HDR %d TDI (0) ",header_dr_le

Re: [Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Tue, Nov 16, 2010 at 11:17 PM, Øyvind Harboe  wrote:
> svf/xsvf has been a somewhat peripheral feature of OpenOCD
> and I couldn't possibly comment on whether this patch should
> be applied or not.
>
> Do you feel it's ready to be applied if there are no protests?
>

Ok just as a follow up I've tested it with the fpga before and after
the arm on the chain (aka I rewired the hardware) and it behaves just
fine when the fpga is targetted by it's name:
openocd.exe -c "svf a3p125.tap test.svf quiet" -c exit

when openocd.cfg contains:
jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf
in the appropriate place

Leaving the command line set to plain executes the svf untouched and
it throws the same svf error as it did before, as it's not expecting a
chain.
Using a different svf that's been generated for the chain works fine
in both plain mode and targetted mode (targetted mode disables the
header/trailer commands just fine).
Using a different svf that's been generated for a different chain also
works fine, as again targetted mode disables the header/trailer
commands in the svf. This same svf fails in plain mode, as expected.

Basically all tests behaved as expected.

I think this patch is perfectly safe and reliable, it's only
question/downside is the modifying of an existing command line format.
I also can't say for sure whether I've really adhered to coding
standards with regard to commenting, structure, variables - but I
tried to base it on existing code around it.

With regard to command line usage, If you try to use the svf command
without new the plain/name switch it does give a usage message:

usage: svf   [quiet]
Command handler execution failed
in procedure 'svf'

which again was made to be consistent with existing usage of xsvf command.

On a related node, is there a standard method of updating
documentation pages? are they accessible via svn/git or something to
easily make patches for updates to them?
My suggestion would be obviously to document the updated svf commands
and probably add to the FPGA/PLD page with a link to the svf page as
an alternative to the less maintained commands there.

Cheers,
Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] Config file format/line endings

[Andrew Leech]

On Tue, Nov 16, 2010 at 12:19 PM, Steve Bennett  wrote:
>
> On 16/11/2010, at 11:15 AM, Øyvind Harboe wrote:
>
>> On Tue, Nov 16, 2010 at 2:06 AM, Steve Bennett  
>> wrote:
>>> On 16/11/2010, at 9:27 AM, Andrew Leech wrote:
>>>
>>>> Hi all,
>>>> I've just found a compiling/usage difficulty with the git version on
>>>> cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
>>>> jimtcl?) openocd no longer handles dos line endings on config files.
>>>> Apparently all my config files of my existing 0.4.0 installation have
>>>> dos line endings and I'd never realised or cared, but I compiled git
>>>> on cygwin and tried to use it with my existing openocd.cfg and was
>>>> treated to this error:
>>>>
>>>> Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00)
>>>> Licensed under GNU GPL v2
>>>> For bug reports, read
>>>>        http://openocd.berlios.de/doc/doxygen/bugs.html
>>>> Runtime Error: embedded:startup.tcl:57:
>>>> in procedure 'script'
>>>> at file "embedded:startup.tcl", line 57
>>>>
>>>> This is a very un-user-friendly error message and had me stumped, I
>>>> though my build was broken or something. It took me a lot of stuffing
>>>> around with config files to realise it was just a dos2unix on my
>>>> config file away from working, and now I'm all good.
>>>> I personally don't have an issue with requiring unix line endings,
>>>> it's just that this is a nasty way to fail, a cleaner error message
>>>> would have been useful.
>>>
>>> I suspect the problem is here in src/helper/startup.tcl
>>>
>>>        set errmsg [format "%s: command requires more arguments" \
>>>            [concat $name " " $args]]
>>>
>>> The backslash newline sequence will likely have a carriage return inserted.
>>> The easy solution is to ensure that these startup files are read in text 
>>> mode
>>> or have the \r\n translated to \n before creating startup_tcl.c
>>>
>>> But it would also be nice if each startup script were evaluated 
>>> independently
>>> with the original filename, and any error message shown.
>>
>> A large startup.tcl is generated by the makefiles from many smaller
>> startup.tcl scripts around the source tree. This startup.tcl is then 
>> converted
>> to .c and linked into openocd. Why? Because it was felt that it was an 
>> important
>> feature to be able to launch openocd without a dependency on the files that
>> openocd ships with.
>
> Nothing wrong with that. Jim Tcl does something similar to allow Tcl 
> extensions
> to be linked in. For example, stdlib.tcl, tclcompat.tcl and glob.tcl
>
> The trick is to invoke Jim_Eval_Named() once for each file so that the 
> original
> source file can be identified, and also to display any error which is 
> generated.
>

I don't know that the line ending problem is with (the compiled in)
startup.tcl. I only did the dos2unix on my openocd.cfg and associated
cfg text files, and then they worked fine with the same openocd
binary.

Is openocd supposed to still work with dos format .cfg files?

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] [PATCH] SVF Chain Handling (was: lpc3131 and Actel FPGA chain programming)

[Andrew Leech]

On Mon, Nov 15, 2010 at 1:05 PM, Andrew Leech 
wrote:
> On Sat, Nov 13, 2010 at 1:28 AM, Peter Stuge  wrote:
>
>>> There's specific HDR and similar commands in svf to define these
>>> paddings.
>>

>>> Some software like UrJtag ignores these commands if they even exist
>>> and figures them out itself by scanning the chain, this is neat.
>>
>> I think this is the only sensible behavior.
>>
>>
>>> The svf player in openocd doesn't have anything like this (and I don't
>>> have time right now how to figure out how to add it, maybe later), so
>>> you're left with generating the svf files to be aware of the chain, if
>>> the software making the svf has this functionality.
>>
>> Or maybe OpenOCD can patch in the neccessary stuff into the SVF?
>>
>
> Yeah I would like to add automatic support for this in openocd, it
> really would be quite trivial. Basically add an optional switch to the
> svf command to target a specific tap which would then ignore any
> header/trailer commands in the svf and run the appropriate command
> before running the supplied svf.

> For reference here's a svf header for my chain (trimmed and commented by
me)
>
>>!# Chain header for configuration of:
>>!#  tap 1: jtag newtap lpc3131 cpu -irlen 4 -expected-id 0x07926f0f
>>!#  tap 2: jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf
>>!#
>>STATE RESET;
>>RUNTEST IDLE 5 TCK 200E-6 SEC;
>>ENDIR IDLE;
>>SIR 12 TDI(00f) TDO(000) MASK(000);    !# put lpc IR = 0xF (bypass mode),
and a3p IR = 0x00 (do nothing?)
>>ENDIR IRPAUSE;
>>HDR 1 TDI(0);          !# Set 1 bit of data header padding (lpc bypass
register at start of chain)
>>HIR 4 TDI(f);          !# Set 4 bits of instruction header padding (lpc 4
bits of IR at start of chain)
>>TDR 0;                 !# no trailer padding (no taps on chain after a3p)
>>TIR 0;
>>!#
>>!# Continue with rest of original SVF
>>FREQUENCY 4E6 HZ;
>>STATE RESET;
>>RUNTEST IDLE 5 TCK;
>>ENDIR IRPAUSE;
>>ENDDR DRPAUSE;
>>SDR 32 TDI() TDO(03A121CF) MASK(06FF);
>>!#
>
> The original header from actel had a few extra tests than is here, I
> trimmed it to basically the minimum that works, and these commands
> would be very easy to auto generate. Not sure if/when I might find
> time to add this to openocd though. Pretty easy to add these commands
> to a SVF manually in the mean time. This header is certainly worth
> having on the wiki page about SVF I feel.
>

Ok so I decided I could add support for this to openocd. The trimmed header
above is still bigger than required, the line where it puts lpc into bypass
mode isn't required either, this was just part of the test on whether the
chain is set up correctly. I feel I can rely on openocd to ensure the chain
is right, so didn't include it in the patch. All I need to do is set the
HDR/HIR/TDR/TIR commands.

The route I took in this patch is to add a new command line switch to the
svf command which mirrors the usage that the xsvf module already has:
"usage: svf   [quiet]"
So if you want to run the svf unmodified specify plain before the filename,
in which case the svf is run exactly the same way as the svf module
currently runs. To target a specific device give its dotted name before the
filename.

When a dotted name is given the code calculated appropriate values for the
HDR/HIR/TDR/TIR commands and manually runs these through the existing
command parser. It then disables these commands in the parser to ensure the
values are not overwritten by any existing commands in the svf file. Seeing
as these commands already work to set up the padding I thought it easiest to
use the existing system rather than finding and directly setting the lower
level settings.

This patch has changed the command syntax from the existing module, so it's
not directly compatible with any users existing scripts if people are using
the svf command. I could put the dotted name as an optional command at the
end (after quiet) if compatibility was preferred, however I thought it best
to make it consistent with the xsvf module command. Any input on this
decision is welcomed.

This patch hasn't yet been tested on any system other than my one custom
hardware, although it's fairly straightforward so I don't see there being
too many issues.

Andrew


svf_chain.patch
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] Config file format/line endings

[Andrew Leech]

Hi all,
I've just found a compiling/usage difficulty with the git version on
cygwin. Apparently somewhere between 0.4.0 and mainline (possibly
jimtcl?) openocd no longer handles dos line endings on config files.
Apparently all my config files of my existing 0.4.0 installation have
dos line endings and I'd never realised or cared, but I compiled git
on cygwin and tried to use it with my existing openocd.cfg and was
treated to this error:

Open On-Chip Debugger 0.5.0-dev-00589-gfdae512-dirty (2010-11-16-10:00)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Runtime Error: embedded:startup.tcl:57:
in procedure 'script'
at file "embedded:startup.tcl", line 57

This is a very un-user-friendly error message and had me stumped, I
though my build was broken or something. It took me a lot of stuffing
around with config files to realise it was just a dos2unix on my
config file away from working, and now I'm all good.
I personally don't have an issue with requiring unix line endings,
it's just that this is a nasty way to fail, a cleaner error message
would have been useful.

Cheers,
Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] lpc3131 and Actel FPGA chain programming.

[Andrew Leech]

On Sat, Nov 13, 2010 at 1:28 AM, Peter Stuge  wrote:

>> There's specific HDR and similar commands in svf to define these
>> paddings.
>
> Can you say more about them? Did you study the SVF output by
> FlashPro? It would be interesting to diff a failing SVF with a
> working one.
>

Yeah I've just been looking into them more. Basically the svf with
chain information is exactly the same as non-chain except for a nice
header block.
They basically just put the lpc into bypass mode which leaves a 1 bit
data register in the jtag chain. The header/trailer commands then just
specify (to openocd) this extra padding bit on any data command and
(in my case) 4 bits of padding on any instruction command.

>From Xilinx xapp503:

To reduce the size of an SVF file, the SVF specification provides four
global padding
instructions: Header Instruction Register (HIR), Trailer Instruction
Register (TIR), Header Data
Register (HDR), and Trailer Data Register (TDR).

HIR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask]    #Specifies
bits to follow subsequent Shift-IR instructions.
TIR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask]     #Specifies
bits to precede subsequent Shift-IR instructions.
HDR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask]   #Specifies
bits to follow subsequent Shift-DR instructions
TDR length TDI(tdi) SMASK(smask) [TDO(tdo) MASK(mask]   #Specifies
bits to precede subsequent Shift-DR instructions.

Note: SVF “Header” instructions specify padding bits at the end of a
shift pattern, while “Trailer”
instructions specify padding bits at the beginning of a shift pattern.
This is a common point of
confusion and can initially seem counterintuitive.
These global commands specify the number of bits to pad the beginning
and end of a shift
operation, to account for bypassed devices, and provide a simple
method of SVF file
compression. Once specified, these bits lead or follow every set of
bits shifted for the SIR or
SDR commands.

It's up the the svf parser (ie openocd) to add these specified padding
bits to all subsequent commands. Luckily for me support for these
commands is already included in openocd's svf module.

>
>> Some software like UrJtag ignores these commands if they even exist
>> and figures them out itself by scanning the chain, this is neat.
>
> I think this is the only sensible behavior.
>
>
>> The svf player in openocd doesn't have anything like this (and I don't
>> have time right now how to figure out how to add it, maybe later), so
>> you're left with generating the svf files to be aware of the chain, if
>> the software making the svf has this functionality.
>
> Or maybe OpenOCD can patch in the neccessary stuff into the SVF?
>

Yeah I would like to add automatic support for this in openocd, it
really would be quite trivial. Basically add an optional switch to the
svf command to target a specific tap which would then ignore any
header/trailer commands in the svf and run the appropriate command
before running the supplied svf.


> 3 minutes is also really slow imo, but it is what it is because of
> how the simple interfaces work. I've ranted enough about that before.
>

Yep 3 minutes does feel like an eternity if you sit and watch it. To
be fair Altium's programmer does take pretty much just as long, it's
their own custom hardware based on a LPC2888 (usb 2 high speed) which
is supported by Alium and nothing else. Personally I'm not changing my
fpga code much currently and I want openocd support primarily for
production guys to use, where 3 minutes I'm sure will be annoying but
not the end of the world. The fact that it works is the most important
aspect. Higher jtag clock speed might help too.

> Thanks! Maybe another option would be for you to just submit a patch
> with the above board file for your board, with some comments in it?
>

Yeah I thought about submitting a board file but as it's a completely
custom hardware setup (it's composed of 3 pcb's wired together
haphazardly) it's not really relevant except as a generic sample. Is
this really suitable for inclusion as a board.cfg?

For reference here's a svf header for my chain (trimmed and commented by me)

>!# Chain header for configuration of:
>!#  tap 1: jtag newtap lpc3131 cpu -irlen 4 -expected-id 0x07926f0f
>!#  tap 2: jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf
>!#
>STATE RESET;
>RUNTEST IDLE 5 TCK 200E-6 SEC;
>ENDIR IDLE;
>SIR 12 TDI(00f) TDO(000) MASK(000);!# put lpc IR = 0xF (bypass mode), and 
>a3p IR = 0x00 (do nothing?)
>ENDIR IRPAUSE;
>HDR 1 TDI(0);  !# Set 1 bit of data header padding (lpc bypass 
>register at start of chain)
>HIR 4 TDI(f);  !# Set 4 bits of instruction header padding (lpc 4 bits 
>of IR at start of chain)
>TDR 0; !# no trailer padding (no taps on chain after a3p)
>TIR 0;
>!#
>!#
>!# Continue with rest of original SVF
>FREQUENCY 4E6 HZ;
>STATE RESET;
>RUNTEST IDLE 5 TCK;
>ENDIR IRPAUSE;
>ENDDR DRPAUSE;
>SIR 8 TDI(0F);
>SDR 32 TDI();
>STATE IDLE;
>RUNTE

Re: [Openocd-development] lpc3131 and Actel FPGA chain programming.

[Andrew Leech]

On Thu, Nov 11, 2010 at 2:44 AM, Peter Stuge  wrote:
>
> Andrew Leech wrote:
> > Now I need to figure out how to bypass the lpc via software rather
> > than physically changing the chain. I can't seem to find much
> > information about how bypass works with openocd, do you have any
> > idea?
>
> Sorry, no idea.
>

Ok I've actually got this working! From my research there's two
typical ways of using a SVF on a chain, either the SVF file has to be
generated to know about the chain or the jtag software has to be aware
of the chain. Basically each ir and dr command needs a header and
trailer padding bytes to cover the other taps on the chain. There's
specific HDR and similar commands in svf to define these paddings.
Some software like UrJtag ignores these commands if they even exist
and figures them out itself by scanning the chain, this is neat.The
svf player in openocd doesn't have anything like this (and I don't
have time right now how to figure out how to add it, maybe later), so
you're left with generating the svf files to be aware of the chain, if
the software making the svf has this functionality.

>
> > Once I have it all sorted out I think this is well worth me making
> > a wiki page for programming fpga's on a chain, as there's not much
> > info about it so far, and it actually seems quite easy once you
> > know what your're doing.
>
> That would be fantastic. At the very least please do send an email
> with what you came up with!
>
>

So yeah, I was initially generating my svf files directly from Actel
Designer Software using the actel project file generated by Altium
Designer (where i do the actual fpga designing). It doesn't allow you
to define chains anywhere, so I though I'd be in trouble, maybe having
to figure out the command manually.

Looking further I found that Actel FlashPro software on the other hand
allows chains to be manually defined (or detect them automatically if
you have their programmer hardware plugged in), and Altium was already
exporting a STAPL file by default which FlashPro was happy to assign
to the fpga that was defined in the chain. Then File->Export->Chain
SVF File and I had svf files complete with chain header and trailer.

The basic openocd command then for me are simply:

source [find interface/luminary-icdi.cfg]                            #
My programmer
source [find target/lpc3131.cfg]
# This is now in mainline :)
jtag_khz 6000
     # Going to try to optimise this later...
reset_config srst_only srst_pulls_trst                              #
My board's only wired to do this
jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf   # The FPGA
init
scan_chain
      # just to be sure they're connected properly
svf Chain_PROGRAM_ARRAY.svf quiet                          # runs my
svf file from flashpro

and it sits there quietly for just over 3 minutes before informing me
it's all done nicely, and I have a working fpga!
When I get a chance I'll make a patch/updates to the wiki page on the
svf player to be a bit more explicit on how to use it.

Cheers,
Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Re: [Openocd-development] lpc3131 and Actel FPGA chain programming.

[Andrew Leech]

On Tue, Nov 9, 2010 at 10:37 PM, Peter Stuge  wrote:

> Andrew Leech wrote:
> > On a different matter, I'm currently using this part on a chain with an
> > Actel A3P125 FPGA
>
> I'd look at buying an IGLOO Icicle ($69 or something). It includes an
> Actel "LCPS" (Low-Cost Programming Stick) which is the equivalent of
> a FlashPro 3, and works with Libero. Just to make sure that
> programming works "their way".
>
> Yeah I had thought it'd be good to get one of Actel's programmers but I'd
have a hard time selling the need to the manager here, seeing as he's seen
me programming my prototype just fine, and I'm not sure I'd have much luck
explaining the need to test something different, especially as it's not
something I'd want to use long term.


>
> > my separate fpga jtag programmer (altium designer and their jtag
> > dongle) doesn't work when it's connected in the chain, I think it's
> > a bit light on the buffering and suffers from noise. It only just
> > works when connected directly to the fpga.
>
> How does this work? Is the LPC still on that chain and you connect
> Altium dongle in between them?
>
> My prototype consists of an off the shelf dev board for the LPC (EA3131)
with the FPGA on a custom board wired into it. As such I've got direct
access to the jtag on each board, I've just wired them into a chain by
making a custom cable to simulate how they'll be wired on the final design.


>
> > I've generated svf files with the actel software and tried playing
> > them with openocd, but it errors out:
>
> I don't believe OpenOCD SVF has been exercised much. You could try
> using UrJTAG instead. I also find Altera's STAPL player source very
> interesting for use with Actel parts, but that road needs a bit of
> work before it could function.
>
>
I actualy did try UrJTAG (even going to the extent of adding TI ICDI support
to is, I still need to submit the patch for that... ) but didn't get very
far there either, the UrJTAG parser didn't like some command or other in the
svf file.


As it turns out I did find the problem, and it's very basic. Amazing how
just writing down the problem thoroughly (to post a question) can be enough
to trigger an obvious idea.
It was a basic chaining issue. I had created the Actel project (with altium)
with the entire chain in place, so thought it would have created a svf file
specifically for the chain. Apparently not. All I had to do was connect the
TI ICDI programmer directly to the fpga's jtag (requiring another new custom
cable as it turned out) and the svf played no worries, and the part was all
flashed and ready to use!

Now I need to figure out how to bypass the lpc via software rather than
physically changing the chain. I can't seem to find much information about
how bypass works with openocd, do you have any idea?

Once I have it all sorted out I think this is well worth me making a wiki
page for programming fpga's on a chain, as there's not much info about it so
far, and it actually seems quite easy once you know what your're doing.

Andrew
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

[Openocd-development] lpc3131 and Actel FPGA chain programming.

[Andrew Leech]

Hi All,
First post, and I'd like to say a huge thanks for such a capable tool! I've
been using openocd (0.4.0 release) to successfully program and debug a
LPC3131 part for a few months now. Bit of a learning curve for sure but well
worth it.
I've attached my lpc3131.cfg, what would be required to get this included in
the official distro?

On a different matter, I'm currently using this part on a chain with an
Actel A3P125 FPGA which seems to be working fine for the LPC. Ideally I
would like to also program the Actel with openocd to streamline programming
of the entire module.  For some reason, my separate fpga jtag programmer
(altium designer and their jtag dongle) doesn't work when it's connected in
the chain, I think it's a bit light on the buffering and suffers from noise.
It only just works when connected directly to the fpga. Rather than fixing
the dodgy programmer I'd much prefer to use my ft2232 one (TI ICDI) for both
parts!

The Actel FPGA has built in flash, which makes it very convenient to use,
just not so convenient to program as it turns out. I've generated svf files
with the actel software and tried playing them with openocd, but it errors
out:

Error: tdo check error at line 38
Error: read = 0x542439E, want = 0x3A121CF, mask = 0x6FF
Error: fail to run command at line 1633
Error: tdo check error at line 38
Error: read = 0x542439E, want = 0x3A121CF, mask = 0x6FF
109052 ms used
svf file programmed failed
Command handler execution failed

For reference, line 38 is:
SDR 32 TDI() TDO(03A121CF) MASK(06FF);
And line 1633:
SDR 26 TDI(000);

Is there any specific setup of the tap I would need to do before running the
svf command? I'm currently just declaring the tap as such:
jtag newtap a3p125 tap -irlen 8 -expected-id 0x02a121cf
Which appears to be enough to keep the chain happy as far as the lpc's
concerned.

I am fairly new to fpga/svf stuff, is there anything I can do to find the
source of this issue, or might there be a different way to flash the actel
with openocd not using svf?

Thanks,
Andrew Leech



lpc3131.cfg
Description: Binary data
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development