Dangerous Prototypes

We finished porting the OpenOCD support code from the USBPROG project to the Bus Pirate. Get the latest source and compiled firmware from here:
http://code.google.com/p/the-bus-pirate ... ce/OpenOCD (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/source/OpenOCD)

This is untested because there's no PC software to work with yet.

You are wondering (in the source code), why do they use 320 byte long packets.

But usbprog jtag has one problem . They are using interrupt transfers on usb, and they send one packet every 1ms - resulting in 300-400 bytes/sec flashing speed. http://forum.embedded-projects.net/viewtopic.php?id=344 (http://forum.embedded-projects.net/viewtopic.php?id=344)

The FT232 that is on BP uses Bulk transfers, so the same problem "should not" occur here.

I would be more than happy to help with this project as I want something a bit better than just wiggler cable ;)

Thanks robots -

Any help would be greatly appreciated. What do you have in mind? Are you able to mod the existing usbprog code to work with a serial port (the Bus Pirate)?

Well ... it should be as easy as replacing all the libusb stuff with serial stuff.

Yup, that's my thought too. I'm not a PC programmer though. I can do the microcontroller stuff, but I can't get OpenOCD to compile (yet).

If you are able to do that, please let me know how I can help.

I have changed the source code, so that it uses serial port. I haven't tried it yet.

Does the code for BP work ? I mean, have you tried to send arbitrary commands and did the outputs work as expected?

No, it has not yet been tested. I used my standard framework for porting things to the Bus Pirate, so it should have at least minimal functionality. There any be bugs though.

If you test, be sure you're using the correct firmware for your bootloader version.

Which one is for the v2go  from preorder 2 ? :)

v2go and v3 use the same firmware now. They shipped with v2 bootloader, but today we released the v4 bootloader upgrade. If you upgrade your bootloader, then you can use the OpenOCD firmware in this download:
http://the-bus-pirate.googlecode.com/fi ... e.v4.1.zip (http://the-bus-pirate.googlecode.com/files/BusPirate.firmware.v4.1.zip)

If you still have v2 bootloader use this one:
http://code.google.com/p/the-bus-pirate ... ghtly/BPv3 (http://code.google.com/p/the-bus-pirate/source/browse/#svn/v3.6/firmware/v3-nightly/BPv3)

At the moment there seems to be a problem with the ds30 Loader bootloader app on Mac/Linux with Mono, so please don't upgrade unless you have access to a windows box:
http://dangerousprototypes.com/2010/01/ ... 4-upgrade/ (http://dangerousprototypes.com/2010/01/18/how-to-bus-pirate-bootloader-v4-upgrade/)

Thanks :) .. I'll have a look at it tomorow.

I have some "results". The openocd wants to talk to Bus Pirate, but it doesn't reply with anything.

The firmware must be working, as the ModeLed turns off.

The log is here http://pastebin.com/m2d36f3b1 (http://pastebin.com/m2d36f3b1)

After each write/read I print out what was actually sent/read.

Atmega32 and PIC different meaning of the direction registers !

My buspirate now blinks as the openocd says ;)

Edit: I have accidentally fried the pullup driver on the pgc pin :(( but i can still enter bootloader

I have found mistake in the main.c WRITE_AND_READ handler.

should be something like:

case WRITE_AND_READ:// buf[1]+buf[2] extra bytes?????
      i = ((uint8_t)buf[1]*256)+(uint8_t)buf[2];
      write_and_read(buf+3, i);        // skip 3 bytes on buf,  size from openocd is actually number of bits used in the buffer (max 61 * 8 = 488)
....
      CommandAnswer(i/8+1); // for future use :) bigger packets
    break;

also in main()

case WRITE_AND_READ:// buf[1]+buf[2] extra bytes?????
                                buf[1]=UART1RX();//get extra byte
                                buf[2]=UART1RX();//get extra byte
                                j=((uint8_t)buf[1]*256)+(uint8_t)buf[2]; //get data packet size
                                j=j/8+1;
                                for(i=0;i<j;i++){
                                        buf[2+i]=UART1RX();
                                }
                                break;

Thanks robots.

I read the notice emails, so I didn't see the edit until just now. Go ahead and make another post for faster service :)



I updated the functions as follows, and committed a new compile for v4 bootloader to the nightly folder. Have you upgraded bootloaders? I can make a compile for v2 bootloader if you need it.
http://code.google.com/p/the-bus-pirate ... -v0c-1.hex (http://code.google.com/p/the-bus-pirate/source/browse/trunk/firmware/v4-nightly/BPv3%26v2go/BPv3-OpenOCD-v0c-1.hex)

Updates...

Main():

    		case WRITE_TDI:// buf[1]+buf[2] extra bytes?????
			case READ_TDO:// buf[1]+buf[2] extra bytes?????
    		case WRITE_AND_READ:// buf[1]+buf[2] extra bytes?????
				buf[1]=UART1RX();//get extra byte
				buf[2]=UART1RX();//get extra byte
				j=((uint8_t)buf[1]*256)+(uint8_t)buf[2]; //get data packet size
				j=(j/8)+1;
			   	for(i=0;i<j;i++){
					buf[2+i]=UART1RX();
				}
				break;

WRITE_AND_READ

    case WRITE_AND_READ:// buf[1]+buf[2] extra bytes?????
      //write_and_read(buf,((uint8_t)buf[1]*256)+(uint8_t)buf[2]);	// size = numbers of byte not bits!!! round up
      j = ((uint8_t)buf[1]*256)+(uint8_t)buf[2];
      write_and_read(buf+3, j);        // skip 3 bytes on buf,  size from openocd is actually number of bits used in the buffer (max 61 * 8 = 488)
    
      #if 1
      // tck 0 tms 0 tdi 0
      CLEARBIT(BIT2_WRITE,BIT2);  // clk
      CLEARBIT(BIT1_WRITE,BIT1);  // tdi
      CLEARBIT(BIT3_WRITE,BIT3);  // tms
      
      // tck 1 tms 0 tdi 0
      SETBIT(BIT2_WRITE,BIT2);  // clk
      #endif

//      for(i=0;i<64;i++)
//		answer[i]=buf[i];

	  j=(j/8)+1;
      for(i=0;i<j;i++)
		answer[i]=buf[i];

      //CommandAnswer(64);
      CommandAnswer(j); // for future use :) bigger packets
    break;

Because WRITE_TDI, READ_TDO and WRITE_AND_READ all share that function in main, I made these updates too:

WriteTDI (now uses buf+3)

    case WRITE_TDI:// buf[1]+buf[2] extra bytes?????
      write_tdi(buf+3,((uint8_t)buf[1]*256)+(uint8_t)buf[2]);	// size = numbers of byte not bits!!! round up
      // tck 0 tms 0 tdi 0
      CLEARBIT(BIT2_WRITE,BIT2);  // clk
      CLEARBIT(BIT1_WRITE,BIT1);  // tdi
      CLEARBIT(BIT3_WRITE,BIT3);  // tms
      
      // tck 1 tms 0 tdi 0
      SETBIT(BIT2_WRITE,BIT2);  // clk
    break;

Read TDO (uses same mods as WRITE_AND_READ

    case READ_TDO:// buf[1]+buf[2] extra bytes?????
      //read_tdo(buf,((uint8_t)buf[1]*256)+(uint8_t)buf[2]);	// size = numbers of byte not bits!!! round up
      j = ((uint8_t)buf[1]*256)+(uint8_t)buf[2];
	  read_tdo(buf+3,j);	// size = numbers of byte not bits!!! round up

      #if 1
      // tck 0 tms 0 tdi 0
      CLEARBIT(BIT2_WRITE,BIT2);  // clk
      CLEARBIT(BIT1_WRITE,BIT1);  // tdi
      CLEARBIT(BIT3_WRITE,BIT3);  // tms
      
      // tck 1 tms 0 tdi 0
      SETBIT(BIT2_WRITE,BIT2);  // clk
      #endif
      //for(i=0;i<64;i++)
	//	answer[i]=buf[i];

	  j=(j/8)+1;
      for(i=0;i<j;i++)
		answer[i]=buf[i];

      //CommandAnswer(64);
      CommandAnswer(j); // for future use :) bigger packets

    break;

Please let me know if you think any of these changes were unnecessary.

I messed up: (lines 121, 148 and 205 of main.c)

j=(j/8)+1;

it should give the number of bytes used by bits, but returns +1 if (j % 8 == 0)

This should work better

j = (j >> 3) + (j & 0x07)?1:0;

Another thing is to route the TRST signal to the output port, i guess that  AUX could do it.

#define BIT5        0b01//jp2right(?)

could be

#define BIT5        AUX

And you can remove all of those BITx_1 stuff (it was in usbprog for backward compatibility)

Too bad we are missing one IO for the SRST. :-/

After these changes i should be able to test it on real hw !

Make the AUx BIT4 instead of BIT5...

According to the wiggler schematic http://www.frozeneskimo.com/electronics ... lersch.png (http://www.frozeneskimo.com/electronics/wp-content/uploads/Schematics/jtagwigglersch.png) the tsrt it not that needed :)

I thought bit 4 and 5 were for a jumper that checked the mode or power supply, or something, on the USBprog hardware. Do you know what they are so I can add a comment in the code?

I didn't remove the BITx_1 stuff yet because it's in a lot of places in the code. Once we get it working I'll take a stab at cleanup.

I made bit 4 AUX in usbprogjtag.h.

I replaced j=(j/8)+1; at three places in the code.

There's a new nightly compile, but it's for bootloader v4 (which do you need?):
http://code.google.com/p/the-bus-pirate ... -v0c-2.hex (http://code.google.com/p/the-bus-pirate/source/browse/trunk/firmware/v4-nightly/BPv3%26v2go/BPv3-OpenOCD-v0c-2.hex)

BIT 4 is SRST
BIT 5 is TRST

I checked with the usbprog firmware (as i own one :) )
My BP was updated to v4 bootloader (sucessfully). I have made a cable that should work with my ARM starter kit.

Ill let you know in few hours, how it went.

right now we recieve message , process it, copy from the buffer to another and send the second buffer.
Do we need separate buffer for outgoing messages ?

There is also a mistake in the copying. You copy 3 bytes less than you should :)

Removing the "answer" buffer would save a lot of troubles.

Thanks for the update.

So far I've only ported the firmware to the Bus Pirate hardware, I haven't tested or optimized. I like to keep ports exactly as the author wrote it so that it's easier to merge future updates into the Bus Pirate port. We can derivative though, especially because you're adding a custom support branch and the firmware is already modded for serial instead of USB.

CommandAnswer(j); // for future use :) bigger packets

will be

CommandAnswer(j+3); // for future use :) bigger packets

I'm make that change and recompile in a few minutes.

Later updates:
remove BITX_1 stuff
single buffer

can you tell me which is the liker script you use ?

I have mplab with C30 compiler, and when i try to load the hex with ds30loader, it tells me that it will overwrite bootloader.
I think this way the development cycle will be far shorter :)

I use the GLD in the folder. The linker needs to be updated to exclude the config bits (if possible) before we can use the compile as-is. Right now you need to:

file->export
uncheck export config bits
set range to 0x00-0xa7fd
save

and that can be loaded.

I updated and checked in the changes. I didn't compile because it sounds like you can do that now.

Forgot to add: uncheck "export config bits".

I did check in a new nightly...

I have fixed a lot of small bugs (like missing parenthesizes). All commands should work as expected. I still cannot connect to my arm target.

I am trying to add more "nop-s" to slow down a bit.

I am almost there :))

http://pastebin.com/m26ab869a (http://pastebin.com/m26ab869a)

The important piece is

Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)

the unpleasant piece is

Warn : Unexpected idcode after end of chain: 480 0x800000ff
Warn : Unexpected idcode after end of chain: 512 0x8000007f
Warn : Unexpected idcode after end of chain: 544 0x0000007f

Im not yet sure, what causes this magic error :( It seems that im getting more data from the jtag than expected

I guess porting of usbprog is finished :) I have found a thread in openocd mailinglist

http://www.mail-archive.com/openocd-dev ... 09493.html (http://www.mail-archive.com/openocd-development@lists.berlios.de/msg09493.html)

It mentions that usbprog only transfers chunks of 64bytes, and that the initial scan in Larger and has to be split, this is where we loose one clock tick. There are some options listed as how to fix this.

I am going to change the usbprog handling so that:
1. We sent the whole thing to buspirate (1024k buffer "should" be enough but we have 8k available just in case ;))
2. remove the TMS handling from WRITE_AND_READ/ WRITE_TDO/ READ_TDI and put it all to openocd driver.

Im not sure what is the impact on overall speed going to be. As we are also on usb as usbprog is. (except we are on 115k uart , can we go faster ? )

That makes sense. I like both changes.

It might be best to develop with a 4096 byte buffer because this is the size of the multi-use buffer in the main Bus Pirate firmware. If we eventually merge OpenOCD support into the main firmware, that is the buffer it will use.

I bet the Bus Pirate will be slower because the USBPROG uses usb bulk transfers, and we're just using a UART. However, the Bus Pirate hardware is faster, so it depends on where it spends most of its time (transfer vs pin twiddling). However, I think both the PIC and FTDI chip will support 1-, 2-, or maybe 3- Mbps, so we could increase the speed a bit.

Thanks for all your great work on this. Would you like SVN access to commit your changes?

I think that ft232 uses bulk transfers as well. At first we should get it to working state :)

Can you add me (xxxx) to the svn ? 
Also I'm having problem with the dos<->unix newline. SVN wants to change the whole usbprogjtag.c file, even though i changed only few lines. Which one do you preffer in the SVN? 

You're added, welcome to the project. I removed your email address from the post.

Use whatever is easiest for you, I won't stress about it.

I got the Jtag working :))

I have just changed the buffer, so the messages do not get split. And it works.

Which buffer is it (input/output)? Does it matter? Do they both need to be extended? I'll start looking at merging them if that's needed. I'll be back in a few minutes and start actively working on this with out if you like.

First real test :) , I have tried to flash my STM32 board. The speed is about 0.8 kb/s

Open On-Chip Debugger 0.3.0-rc0 (2010-01-18-17:44)
$URL$
For bug reports, read
   http://openocd.berlios.de/doc/doxygen/bugs.html (http://openocd.berlios.de/doc/doxygen/bugs.html)
tms sequence is  long
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
jtag_nsrst_delay: 100
jtag_ntrst_delay: 100
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain
Warn : stm32.bs: nonstandard IR mask
Warn : use 'stm32.cpu' as target identifier, not '0'
20
Info : Buspirate Interface ready!
Error: Translation from khz to jtag_speed not implemented
Error: Translation from jtag_speed to khz not implemented
Error: Translation from khz to jtag_speed not implemented
Info : interface specific clock speed value 1000
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : device id = 0x20036410
Info : flash size = 128kbytes
stm32x mass erase complete
Info : Padding image section 0 with 0 bytes
wrote 31840 byte from file ./stm32_menu.elf in 38.119694s (0.815687 kb/s)
requesting target halt and executing a soft reset
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08002790 msp: 0x20005000
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)

0.8 kb/s sounds awful. Are all the writes sent one bit per byte? What do you get with a wiggler?

It does bit-banging, and sends data in 2 byte chunks.

I guess that modifying the protocol a bit, so that the bitbanging sequence is sent over to buspirate would help a lot

I didn't realize everything was bit-banged. I knew there was bitwise control to do stuff like read a pin while exiting a state with TMS, but I thought some stuff went bytewise.

How about a hack to add a byte read_write packet type. It seems like most of the work inbetween state machine changes could be done bytewise and increase the speed a lot. The only issue I see is that it would have to be started and ended bitwise, and the current firmware resets all the pins so we'd end up with a bad bit in the transition. Maybe we can move all the redundant pin reset code in the three read/write functions to a separate packet type too and have the code send that?

If you'd like to meet today in IRC or IM, please let me know. I've got some time to work on this today.

just some stuff was bitbanged,  in openocd it is called runtest, it does some changes on the tms bit.

I have queued these bytes and sent them over to BP in one piece, and let the BP do the work.
(much like WRITE_TMS_CHAIN)

I got to something like

wrote 31840 byte from file ./stm32_menu.elf in 27.153990s (1.145090 kb/s)

The wiggler gets about 14kb/s

I'm attaching log file, so you can see what is going on in there

I studied up a bit and understand it now. It reads and writes bits, but an arbitrary number all packed into a byte stream.

I also see where it just toggles the TMS line on the last bit of a packet. That is an unfortunate. I thought it used separate bitbang commands so the TMS manipulation could be at an arbitrary time. Everything has to fit in a single buffer packet or it dies. (as you said previously). How important is that, what is the maximum working packet length? Does it pose a big disadvantage in practical terms?

Any ideas to improve speed? Is it the link or the routines? The theoretical throughput of 115200bps is 12800cps (say 8-10kb/s to be safe). It would be nice if we could get to 5kb/s. I don't see many possibilities for speed increase though, can the 255 nops per clock tick be reduced in read_write, tdi, and tdo? Could they be made configurable if they need to be slow during one phase and fast during another?

I have those 255 nops removed in my code. But what i didnt know is that, openocd gives you chain of commands and waits for answers.

I have been looking on other jtag interfaces, and i like the idea of arm-jtag-ew.

They have 2 buffers tms and tdi.
When you are doing a scan or tms walk you fill the buffers with the bits, which you want to shift out. Send those buffers over to the interface, and the interface shifts out all the bits, and shifts in TDO values. Reply is the buffer of TDO bits.
You just have to divide received bits into chunks (scans), and pass them to openocd.

Activity on TMS does "walk" in the state-machine of JTAG

http://infocenter.arm.com/help/index.js ... edcid.html (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0151c/Babedcid.html)

And activity on TDI/TDO does shift out/in data in the current state. (there are few states considered stable, like PAUSE, SHIFT, IDLE, ..., but not EXIT, ... )

Also, we're wasting a lot of time sending large datapackets back and forth then doing everything. The PIC has a 4 byte UART buffer, it would be great to at least take advantage of that when sending data back to the PC. As it is, we load it up, then waste time time waiting for the buffer to clear, add more bytes, etc. For fast operations that won't timeout (or sends) we could send each byte as we assemble it, only hitting the blocking wait if the buffer is currently full.

[quote author="ian"]
Use whatever is easiest for you, I won't stress about it.
[/quote]
If I remember the svn manual correct there is a server setting for this. Set eol-style to native and the
server will ensure that the repository has consistent line endings.

Klaus Leiss

You've made fantastic progress, thank you for working on it. What do you think about integrating support into the main Bus Pirate firmware?

I think there's room. I'd like to write new code (license compatible) for the current protocol, and add a new binary mode (http://dangerousprototypes.com/2009/10/ ... bang-mode/ (http://dangerousprototypes.com/2009/10/09/bus-pirate-raw-bitbang-mode/)). The functions in binIO.c and bitbang.c (used in I2C, raw2 and raw3 wire) can probably replace a lot of usbprogjtag.c.

I'm working on a stub and I'll check it in soon.

I just noticed that we send the number of bytes we want to read on a TDO read? Is that right? Is there any reason for that? It doesn't seem to use the buffer for anything, but my read loop gathers the 64 bytes anyways. That could be a big speed improvement.

I know there is a bug in READ_TDO, but ... its not used in my flashing :) so i have not fixed it

I have writen new function in firmware and rewriten the openocd driver. (almost finished debugging - just some minor problem with reading bits)

If this works, there is going to be only one function in the BP firmware (small and preferrably fast) + function to control SRST/NRST

Got the new firmware and openocd driver working :))) (pure magic that it even works (: )

I have taken the idea of arm-jtag-ew as i said earlier.

The speed now is

wrote 31840 byte from file ./stm32_menu.elf in 21.471720s (1.448126 kb/s)

Attaching log, Everytime you see something like "executing tap" we are sending stuff. Compared to the old log, this is much better, much less transactions, and transactions are bigger.
Now the question are ...
Can we use interrupt transfers in pic ? (would it be possible to integrate to BP firmware?)
Can we go faster with serial port ? (and not break up other BP stuff)

I'm going to check in the firmware into svn.

Some calculations:

grep buspirate_tap_execute ./log2.log | wc -l
672

totaly 672 transfers

grep buspirate_tap_execute ./log2.log | cut -d" " -awk 'BEGIN {a=0;} {a+=$1} END { printf a; printf "n" }'
604612

Totaly transfered 604621 bits  roughly 75578 bytes
That means 75578*2 + 672 * 3 = 157172 bytes were sent to BP
and 75578 + 672*3 = 79594 bytes were received from BP
As we are doing "half duplex" totaly 236766 bytes transfered!!!

@115200:
115200 baud (8bits + start + stop) = 11520 bytes/second

236766/11520 = 20.6 seconds

It seems that the actual bitbanging and openocd "thinking" took only ~1second!!

I don't think I can do any better at current rate :)

I know that people LOVE pictures :))

Here are some of my setup:
http://robot.mysteria.cz/21012010029.jpg (http://robot.mysteria.cz/21012010029.jpg)
White cable is my "handle", so i can remove the connector :)
http://robot.mysteria.cz/21012010030.jpg (http://robot.mysteria.cz/21012010030.jpg)

The pinout for the cable is:

BPJTAG 20 pin
BLACK104,6,8,10,12,14,16,18,20
YELLOW49
ORANGE35
RED27
BROWN113
GREEN515
WHITEPGD3

The white cable is not connected to the 10pin connector, its should be connected to the programming header's PGD signal (not needed in my case)
The gnd can be connected to any of those (4 in my case)

If anyone wants to try out, i have uploaded everything to SVN:

patch for openocd-0.3.0-rc0 and compile/use instructions:
http://code.google.com/p/the-bus-pirate ... irate.diff (http://code.google.com/p/the-bus-pirate/source/browse/trunk/documents/openocd-0.3.0-rc0-buspirate.diff)

Firmware for v4 bootloader:
http://code.google.com/p/the-bus-pirate ... OCDv01.hex (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/OpenOCD/OpenOCDv01.hex)

Everything is in "works for me" state, if anyone could test, i would be happy :)

Fantastic work. I'll post it up with your pics today. Nearly doubling the speed in a day is great!

Integrating interrupts in the Bus Pirate firmware in a logical way could be difficult. Nothing currently uses them, but that doesn't mean it can't.

The speed can be increased to a certain point, but the error of the internal crystal will eventually cause problems on some PICs. We could add a command to OpenOCD mode that increases the speed of the UART, and OpenOCD could close the port, reconfigure it, and open it again. We could require a certain character (usually 55h) to continue, if it's incorrect (baud rate error) then the PIC returns to the lower baud rate.

I've successfully setup my v3 Bus Pirate for OpenOCD JTAG. I had to jump a few hurdles on the way, so for anyone else who's trying my notes might be useful.

http://blog.hodgepig.org/articles/00003 ... index.html (http://blog.hodgepig.org/articles/000034-buspirate/index.html)

Thanks.

I am working on the "replugging" issue.
But if you connect to openocd telnet port (4444 by default) and issue shutdown command, it exits correctly. No replugging necessary.

Thanks for the shutdown tip.

I've just been able to do a like-for-like speed test of the Bus Pirate v3 vs. Olimex's USB OCD (FT2232 based) for programming a Stellaris LM3S9B90 (ARM Cortex-M3) over JTAG.

Bus Pirate:
wrote 34380 bytes from file OS/gcc/os.bin to flash bank 0 at offset 0x00000000 in 6.764177s (4.964 kb/s)

Olimex USB OCD:
wrote 34380 bytes from file OS/gcc/os.bin to flash bank 0 at offset 0x00000000 in 3.577939s (9.384 kb/s)

Not bad at all...

I get around ~5Kb/s for Cortex-M3

But I think that something in your setup is wrong. With Olimex OCD you should have speeds much higher. BP does about speeds around 200-500kHz, Olimex OCD is FT2232 based, and should support up to 12MHz.

The speed of jtag on CM3 is 1/6th of the clock. On STM32 the internal osc is abou 8Mhz, so Jtag speed 1.3MHz can be used. (not sure about stellarit, please consult datasheet). The flashing speed should be much higher than can be obtained by BP. (my gusess is about 10kb/s

The speed when CPU is running full speed (72mhz on stm32, stellaris go up to 120 on some chips), the flashing speed should rise to about 100-300kb/s :)

This is only a theory, as my other jtag (olimex ocd) adapter is on the way.

I have been trying to get my BusPirate and Openocd working to un-brick a linksys WRT160NL (which is a MIPS device using an Atheros 9130 SoC) that has a corrupt u-boot.

When using the buspirate driver for openocd (compiled from latest GIT source) and I try to halt the jtag device I get the error "BUG: unknown JTAG command type encountered" and openocd crashes out. After doing a bit of searching on the net, I came across a post that said the jlink driver was missing JTAG_STABLECLOCKS from the source and after having a look in the buspirate.c driver, I found that it was also missing the JTAG_STABLECLOCKS command. I crudely attempted to hack this in from another driver that did have the command, and have managed to get things moving past this point and can get the device to halt, but I keep getting read/write errors so I think I may have done more harm than good in doing so.

My question is, how important is this JTAG_STABLECLOCKS command, and should it be included in the driver or is there a better way to work around getting my device to halt without it? Has anyone else experienced a similar error while trying to jtag a mips device?

I have implemented the code for you, it should work, i have not tested it yet :)  I need to clean up some stuff so i can push it upstream.
Here is my implementation:

static void buspirate_stableclocks(int num_cycles)
{
  int tms = (tap_get_state() == TAP_RESET ? 1 : 0);
  buspirate_tap_make_space(0, num_cycles);

  for (i = 0; i < num_cycles; i++)
    buspirate_tap_append(tms, 0);

}

Also need to add another case to the main switch:

   case JTAG_STABLECLOCKS:
     DEBUG_JTAG_IO("stable clock %i cycles",  cmd->cmd.stableclocks->num_cycles);
     buspirate_stableclocks(cmd->cmd.stableclocks->num_cycles);
     break;

All it does, it tick clock, I have not needed it on the ARM i am testing with.
The code was pretty much stolen from bitbang.c :)

robots, I have some issue making openocd working and as bp is enabled in openocd, issue must be with connection.

I have jtag pinout in the board manual

1,3 NC
2,4,6,8,10,12,14,16,18 GND
20 VTARGET
5 RES#
7 TDO
9 RTCK
11 TCH
13 TMS
15 TDI
17 TRST
19 VTREF

I see that you are using v2go (I'm using bp 3b)... you also connected PGD to pin3 on JTAG but I see here that pin3 is NC on my board

so I connected BP to JTAG

BP      JTAG

GND     2 (gnd)
CLK     9 (rtck)
MOSI    5 (res#)
CS      7 (tdo)
MISO   13 (tms)
AUX    15 (tdi)

buspirate.cfg is there

[root@luckey openocd]# cat buspirate.cfg 
interface buspirate
buspirate_port /dev/ttyUSB2
buspirate_speed normal
buspirate_vreg 0
buspirate_mode normal
buspirate_pullup 0
reset_config srst_only

[root@luckey openocd]# openocd -f buspirate.cfg -f stm32.cfg 
Open On-Chip Debugger 0.5.0-dev-00551-g7e4cf8d (2010-10-04-22:36)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : Buspirate Interface ready!
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 1000
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms
Polling target failed, GDB will be halted. Polling again in 6300ms
Polling target failed, GDB will be halted. Polling again in 6300ms
Polling target failed, GDB will be halted. Polling again in 6300ms
^C
[root@luckey openocd]# 

Any hints?

---

fast mode, open-drain .. same thing

[root@luckey openocd]# openocd -f buspirate.cfg -f stm32.cfg 
Open On-Chip Debugger 0.5.0-dev-00551-g7e4cf8d (2010-10-04-22:36)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : Buspirate switched to FAST mode
Info : Buspirate Interface ready!
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 1000
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
...
^C

/me confused

and another try ...

open-drain

BP - JTAG
VPU - VTref(3v3)
GND - GND
MOSI - TDI
MISO - TDO
CLK - RTCK
CS - TMS

[root@luckey openocd]# cat buspirate.cfg 
interface buspirate
buspirate_port /dev/ttyUSB2
buspirate_speed fast
buspirate_vreg 0
buspirate_mode open-drain
buspirate_pullup 1
reset_config srst_only
[root@luckey openocd]# openocd -f buspirate.cfg -f stm32.cfg 
Open On-Chip Debugger 0.5.0-dev-00551-g7e4cf8d (2010-10-04-22:36)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : Buspirate switched to FAST mode
Info : Buspirate Interface ready!
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 1000
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: Trying to use configured scan chain anyway...
Error: stm32.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Warn : Invalid ACK 0x7 in JTAG-DP transaction
Polling target failed, GDB will be halted. Polling again in 100ms
Polling target failed, GDB will be halted. Polling again in 300ms
Polling target failed, GDB will be halted. Polling again in 700ms
Polling target failed, GDB will be halted. Polling again in 1500ms
Polling target failed, GDB will be halted. Polling again in 3100ms

IT WORKS :D

[root@luckey openocd]# openocd -f buspirate.cfg -f stm32.cfg 
Open On-Chip Debugger 0.5.0-dev-00551-g7e4cf8d (2010-10-04-22:36)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
srst_only separate srst_gates_jtag srst_open_drain
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
Info : Buspirate switched to FAST mode
Info : Buspirate Interface ready!
Error: Translation from jtag_speed to khz not implemented
Info : adapter-specific clock speed value 1000
Info : JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1)
Info : stm32.cpu: hardware has 6 breakpoints, 4 watchpoints
Warn : stm32.cpu -- clearing lockup after double fault

the proper connection:

BP   - JTAG
VPU  - VTref(3v3)
GND  - GND
MOSI - TDI
MISO - TDO
CLK  - TCK
CS   - TMS 

:)

Congrats! :)

well, combo of not knowing the jtag basics + lack od documentation cost me many hours ... that's why I added the info to the wiki so the next noob gets it faster :)

Thanks. I started a new page and moved the info there:
http://dangerousprototypes.com/docs/Bus ... or_OpenOCD (http://dangerousprototypes.com/docs/Bus_Pirate_JTAG_connections_for_OpenOCD)

Connection of OpenOCD jtag is not much different from Jtag available in BP menu.

One difference is the Reset pin that is available on AUX pin. I have also updated Wiki.  You will really need it when debugging/developing using jtag :)

ah cool, so AUX - #RES is one more connection ..

thing is I connected using what I found in the manual/blogs but either the pinout of the JTAG I have or pinout of those from the manuals/blogs are wrong.... when I finally dropped the "black to 7" and read the bp manual I made it working :) ... it actually looks like that 20pin jtag connector is far from standardised ... I for now seen two major pinouts (1,3,5,7,9...)
TRST, TDO, TDI, TMS, TCK... and Vtref, TRST, TDI, TMS, TCK, RTCK, TDO, RES...

I hoped they are all the same :( .. spent many hours because I was too lazy to open a manual for my board and check the pinout

I personally prefer single pins, and stick them where they belong :) This way i don't need many different cables, and I can do trick with jtag solder pads on board (20pin connector is WAY too large) - see attached picture

---

I agree it is better solution (maybe having single row few pins header would be better then pads but ..) I just hoped that 20pin one was standard but as now I know it is not I don't see any reason for having 20pin connector on any of my boards :D (for jtag of course)... thing is I have no idea what all jtag pin's are (RTCK?, TMS?, TRST vs RES...) but looks like the last not all of them are used ... also, from what I can read tdi/tdo should be linked in chain and jtag connector should attach to first (tdi) and last (tdo) chip's...

I'm doing my best to document the JTAG pins on the Bus Blaster (also 20 pin output). Here's what I've done so far. I'll try to update it with more definitions tomorrow and a table for all 20 pins:

http://dangerousprototypes.com/docs/Bus ... onnections (http://dangerousprototypes.com/docs/Bus_Blaster#JTAG_pin_connections)

Hi,
where can i find buspirate firmware with jtag/opeocd support? links in this topic not working, from this site also - http://blog.hodgepig.org/2010/04/13/545/ (http://blog.hodgepig.org/2010/04/13/545/)
(i have bootloader v4.4 and v5,6 firmware)
regards
Marcin

Hi duppa,

That version should have OpenOCD support.

You can find the latest upgrade info here:
http://dangerousprototypes.com/docs/Bus ... e_upgrades (http://dangerousprototypes.com/docs/Bus_Pirate#Firmware_upgrades)