search

m1a0yu3 / the-bus-pirate

Automatically exported from code.google.com/p/the-bus-pirate
Other
0 stars 1 forks source link

BP gets locked in bit-bang mode. #50

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
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.

Original issue reported on code.google.com by 2lostki...@gmail.com on 17 Mar 2010 at 3:00

GoogleCodeExporter commented 8 years ago 
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}{0
0}{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.

Original comment by ianles...@gmail.com on 17 Mar 2010 at 7:34

GoogleCodeExporter commented 8 years ago 
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.

Original comment by 2lostki...@gmail.com on 17 Mar 2010 at 9:54

GoogleCodeExporter commented 8 years ago 
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.

Original comment by ianles...@gmail.com on 17 Mar 2010 at 10:06

GoogleCodeExporter commented 8 years ago

Original comment by ianles...@gmail.com on 15 Aug 2010 at 8:08