Binary Mode misbehaves after receiving 20 zeroes at once

September 27, 2011, 06:53:11 pm

Hi all:

I wanted to use the Bus Pirate to debug an OpenRISC FPGA soft core over a JTAG adapter.

The OpenOCD project already supports the Bus Pirate for ARM targets, so I figured
I "just" had to port the source code from OpenOCD to the OpenRISC equivalent.

I haven't got an ARM target at hand, but I can still use OpenOCD to scan the JTAG chain,
and that works. Well, not it didn't at first. As it turns out, the latest
official version 5.10 for the Bus Pirate does not have the OpenOCD mode enabled.
There is already a bug open about this, see here:

http://code.google.com/p/the-bus-pirate ... tail?id=59

So I'm testing with an unofficial version I found in a forum here:

viewtopic.php?t=1702#p17536

By the way, I would help if someone from the Bus Pirate team could make a new official version
with the OpenOCD support built in. It the head version is not stable at this point,
some version 5.10b or 5.11 would suffice.

Anyway, before porting the Bus Pirate code from OpenOCD to OpenRISC, I wanted to make sure
I understand how the whole thing works. I noticed that, if OpenOCD gets abruptly interrupted
(if it crashes, and I also have a tendency to press Ctrl+C to quit), then
I have to pull the USB cable from Bus Pirate and reconnect it, otherwise OpenOCD
won't connect to the Bus Pirate any more. I found that annoying, so I tried to fix it.

I thought that was some issue in the OpenOCD code, but it seems that the Bus Pirate
does not recover from a buffer overflow condition that apparently results from sending 20 zeroes
while it's already in Binary Mode.

Let's recap at this point: if the Bus Pirate is in "normal" menu mode, then sending 20 zeroes
puts it into Binary Mode. However, if it's already in Binary Mode, the protocol is designed
to stay in that mode. For every zero received, Bus Pirate replies with "BBIO1". If you send
20 zeroes at once, you should get 20 replies, but you do get many less, so I guess
some buffer overflows at some point. That's quite OK, so long the Bus Pirate stays
in Binary Mode. But it gets confused, and while it looks like it is still in Binary Mode,
it does not properly react to any further Binary Mode commands any more.

I couldn't see anything obvious in the Bus Pirate firmware source code, but I'm no expert there.
However, I did write a Perl script to reproduce this problem, it's attached to this e-mail.

I have reproduced the problem under both Ubuntu and Windows Vista. Because the official
Bus Pirate 5.10 version does not include support for the OpenOCD mode, the script
uses the SPI raw mode instead. This is the log output against the official 5.10 version:

Opening serial port COM3...
Enter Binary Mode... OK.
Go into Raw SPI mode:
Sending: 0x01
Received: SPI1
Come out of Raw SPI mode into Binary Mode:
Sending: 0x00
Received: BBIO1
Go once again into Raw SPI mode:
Sending: 0x01
Received: SPI1
Come out of Raw SPI mode into Binary Mode, no problem:
Sending: 0x00
Received: BBIO1
Stay in Binary Mode:
Sending: 0x00
Received: BBIO1
Go once more into Raw SPI mode:
Sending: 0x01
Received: SPI1
Come out of Raw SPI mode into Binary Mode, no problem:
Sending: 0x00
Received: BBIO1
Try to stay in Binary Mode 20 times. Note that you get fewer replies, as some buffer overflowed:
Sending: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Received: BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1
Sleep one second.
Try to stay in Binary Mode once more, it's apparently OK:
Sending: 0x00
Received: BBIO1
Now try to change to Raw SPI mode, this fails, as you can see in the reply:
Sending: 0x01
Received: BBIO1

See the perl script source code for details.

I've already spoken with Michal Demin, the author of the OpenOCD support code, who has advised me to post to this forum.

Can someone help me with this issue?

This is my Bus Pirate version:

Bus Pirate v3b
Firmware v5.10 (r559) Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com

Many thanks in advance,
R. Diez

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #1 – September 27, 2011, 08:39:45 pm

Im the bus pirate team so you want me:)

You will overflow the 3 byte buffer if you send 4 0x00 at once. Best practice is to send one at a time and check for a reply - if none then send another. In practice you can send one, check, and send 19 more if you get no reply. Unfortunatly the bus pirate has no idea if you ctrlc out of openocd, so it has to be handled elsewhere.

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #2 – September 27, 2011, 09:05:49 pm

Overflowing the buffer is fine in this scenario, it does not matter if many of the 0x00 bytes get lost. But shouldn't the Bus Pirate firmware recover from the overflow and continue to function normally afterwards?

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #3 – September 28, 2011, 08:46:18 am

Quote

But shouldn't the Bus Pirate firmware recover from the overflow and continue to function normally afterwards?

The overflow is handled properly in the terminal mode, but not the binary mode. Binary mode uses so many direct UART calls that I didn't add it to save space. I will try to add a new macro or function in the next update.

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #4 – September 28, 2011, 08:54:43 am

Actually, now I see what is going on. I think the OpenOCD mode (written by robots) uses an interrupt routine. I'll need to investigate because I've never worked with it before.

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #5 – September 30, 2011, 06:04:13 pm

The interrupt routine disables itself automatically after receiving given number of bytes, and it not enabled until receiving correct command in OpenOCD bin mode. So i guess there is no problem in my routine :-)

Re: Binary Mode misbehaves after receiving 20 zeroes at once

Reply #6 – October 06, 2011, 02:14:59 pm

Ok, I'll keep investigating mine. Until then, you should be ok if you do a slight pause between each byte. I'm sorry it isn't an ideal solution, but it is backwards compatible :)