+++ David Brownell [2009-10-26 12:02 -0700]: > On Monday 26 October 2009, Wookey wrote: > > OK. results of today's testing on 0.3.0-dev-00427-g8b30f22 > > (2009-10-26-13:18) > > > > ... > > > > I get > > xsvf processing file: "vhdl/cpld/l3cpld.xsvf" > > Error: XSVF: 'XSTATE IREXIT2' ... NYET > > unsupported xsvf command (0x00) at offset 48, aborting > > Runtime error, file "utils/openocd/loadcpld.cfg", line 6: > > > > More tests later (on .svf, single chain etc), but that's > > the fundamental r1614 regression. > > Though maybe a bit more specific about the issue. :) > > > > The xsvf file is available here: > > http://balloonboard.org/files/balloon3/openocd/bugrep/ > > With an SVF sibling. Does that SVF version work OK?
No, but then I wouldn't expect it to in this case. The xsvf command allows the specification of a tap which means that an XSVF file nominally created for a single JTAG port still works with chained ports (magically - I wasn't expecting openocd to be that clever). The svf command doesn't have that option so the svf probably shouldn't work. I need to re-arrange hardware in order to do the direct side-by-side single-port test and/or generate files for chained-port use. BTW does anyone here know how to use the xilinx tools from the command line so that I can generate such files from a makefile rather than with a load of pointing and clicking? > The deal is that until someone (maybe me) writes code > to more or less morph sequences of XSTATE opcodes into > a pathmove() command, the SVF code can do pathmoves > while XSVF can't. OK. Could you elaborate a bit on why it used to work, but now the above is needed. I've just spent half the day reading the xilinx svf/xsvf spec so I am getting some idea of what's going on. I may be in a position to do some more intelligent debugging soon. Wookey -- Principal hats: iEndian - Balloonboard - Toby Churchill - Emdebian http://wookware.org/ _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
