My command line tools

[jhrose]

But why doesn't it do that at bootup already then? I'm missing something here, I guess.

Not sure but according to [datasheet, section 3.3] the 2232 comes up by default in rs232 mode (unless configured otherwise in the eeprom) and [section 8.0 table 8.1] in rs232 mode pin 13 isn't pulled up.

Let me know if you get any further,

I added the following code before sending the "bit-bang mode MPSSE" command, and the XC-1 seemed to behave well.

Code: Select all

#        if defined( _XC1 )&&( 1 == _XC1 )
        {
            /* PROBLEM on XC-1:
                Unlike XC-1A, the XC-1.FT2232D.ACBUS1 gates transistor Q12, enabling RESET_ to flow;
                this resets the XS1 chip. This is obvious when LED17 (PLL_LOCK) extinguishes on setting
                MPSSE mode. So pre-program upper byte output value (ACBUS0:3).

                cmd=0x82 : set ACBUS0:7 dir and initial states - see FTDI 2232D datasheet 3.3, AN135 p:18 and AN108 table 2-1
                0x82 = Configure data bits high-byte of MPSSE port
                0x00 is initial state (GPIOH0:2=0, GPIOH3=x)
                0x03 is direction (TRST_=out, RESET_=out, DEBUG=in, GPIOL3=in)
            */
            jtag_system_reset_clear( );
        }
#        endif

This should be safe to add for all cases, not just the XC-1.

Unfortunately I still read back 0xffffffff from the target registers, but this is probably something I've clobbered in the Win32 port...

[segher]

But why doesn't it do that at bootup already then? I'm missing something here, I guess.

Not sure but according to [datasheet, section 3.3] the 2232 comes up by default in rs232 mode (unless configured otherwise in the eeprom) and [section 8.0 table 8.1] in rs232 mode pin 13 isn't pulled up.

... but it's an output in UART mode (SLEEP#), and high. Even more confused now.

I added the following code before sending the "bit-bang mode MPSSE" command, and the XC-1 seemed to behave well.

But you cannot send that command before you are in bit-bang mode; if e.g. you
are in UART mode, it will be sent as UART TX data.

Unfortunately I still read back 0xffffffff from the target registers, but this is probably something I've clobbered in the Win32 port...

A good way to test basic JTAG functionality is to add a call to jtag_print_ids() at the
end of jtag_reset(); it should print something like

Code: Select all

        Unknown
        00104731

I might have a patch for XC-1 later today, btw. I'll keep you posted.

[jhrose]

I might have a patch for XC-1

The latest version of segher's command line JTAG tools includes support for both the XC-1 and XC-1A boards. I've put a win32 port of this latest version with the sources including Visual Studio 6 project files and built executables at http://www.jhrose.dial.pipex.com/xmos/J ... _Win32.zip.

The win32 port uses the Open Source libusb-win32 and the binary version 1.2.1.0 is included with the zipfile; or you can download this library from http://www.libusb.org/wiki/libusb-win32. The zipfile "docs and links" folder includes the text file _README_libusb_jhr.txt which summarises how to install (and un-install) libusb-win32.

[segher]

Just a quick note to say that I've updated the project page. Changes since the
last update include:

* command line options: select core #, show available devices, show stats, show help;
* the {p,s,ps}regs commands have much nicer output now;
* some speed improvements, esp. to "dump";
* works on x86 as well now (oops!);
* a simple build config mechanism; the default works on most Linux and OSX systems;
* a new tool, "resources", prints the state of all resources;
* various minor fixes and improvements;
* and, last but not least, support for XC-1 and XTAG (tested on XC-2), in addition
to the XC-1A support.

Please test it out, let me know what you think, report bugs, suggest improvements,
etc. :-)