What steps will reproduce the problem? 1. Use RealTerm to send 27 bytes of 0x0. 2. BP resturns with "BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1BBIO1" which is correct. 3. Try to exit bit-bang mode by sending 1 byte of 0xF. 4. BP responds with "BBIO1" which is incorrect. 5. Doesn't matter how many 0xF are now sent, cannot exit bit-bang mode. Also appears you cannot enter any deeper modes, I2C, SPI etc. BP always responds with BBIO1.

What is the expected output? What do you see instead? The BP should exit bit-bang mode and report: Bus Pirate v3 Firmware v4.2 Bootloader v4.2 DEVID:0x0447 REVID:0x3043 (B5) http://dangerousprototypes.com

Funnily enough if you use the same procedure but only send 26 bytes the BP responds correctly.

What version of the product are you using? On what operating system? Bus Pirate v2.go Firmware v4.2 Bootloader v4.2 DEVID:0x0447 REVID:0x3043 (B5)

Please provide any additional information below.

This is causing a problem when trying to script the BP and reset it from an unknown state. It is very easy to get it locked up.

Are you flooding it with bytes (sending 27x 0x00 at at once?) It might be overflowing or corrupting the cache.

I could not reproduce the problem with the Hercules Setup utility (www.hw-group.com):

HiZ>{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{0F}{01}{0D}{0A}Bus Pirate v3{0D}{0A}Firmware v4.2 Bootloader v4.4{0D}{0A}DEVID:0x0447 REVID:0x3042 (B4){0D}{0A}http://dangerousprototypes.com{0D}{0A}HiZ>{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{00}BBIO1{0F}{01}{0D}{0A}Bus Pirate v3{0D}{0A}Firmware v4.2 Bootloader v4.4{0D}{0A}DEVID:0x0447 REVID:0x3042 (B4){0D}{0A}http://dangerousprototypes.com{0D}{0A}HiZ>

Could you please test your Bus Pirate with this utility? Do you have any more suggestions for reproducing the problem? It seems like a com problem instead of a firmware problem because the Bus Pirate just listens to bytes and responds, there's not much room to misinterpret values.

I was just going to retry this at home with the Hercules Setup utility. Firstly I tried to recreate the problem using Realterm and to my surprise it worked. The only difference was that I was using a BPv3a:

Bus Pirate v3 Firmware v4.2 Bootloader v4.2 DEVID:0x0447 REVID:0x3003 (A3) http://dangerousprototypes.com

I have left my other BP at work. I will bring it home and retry tomorrow. I am pretty sure the problem is reproducable as I was having it at home before with the v2.go.

I was sending the 27x 0x0 all at once and it was entirely possible that this was overloading the BP. The strange thing is once this had happened is that you could no longer exit BBIO mode, nor could you enter any deeper levels SPI, I2C etc. I would not have expected that.

I will certainly follow up and try to provide more information.

Let's move further discussion to the forum if that's ok with you, I think we'll get a lot more feedback and testers.

The hardware UART is only 4bytes, so after it says BBIO1 the first time the output buffer is full and the input buffer is full. More bytes raise an error flag and do funky stuff. We could probably look at the input function and make sure it detects and clears the framing and buffer errors when they occur. The work around (that fixes this issue with all previous firmware versions too) is to send 0x00 and then check for bbiox. it may take 1 or 20 times 0x00 to get into bbio mode (depending on user terminal mode, in a binary mode already, or previous state) so the best practice if to send one 0x00 byte at a time and check for the output. The perl scripts in the example script folder in SVN use this approach.