With aphoticjezter’s confirmation that the undocumented I2C sniffer actually works, we tweaked the code to help get around the UART speed limitations. These updates are in the latest nightly build.
The I2C and SPI sniffers now use a 4096byte output ring buffer. Sniffer output goes into the ring buffer and gets pushed to the PC when the UART is free. This should eliminate problems with dropped bytes, regardless of UART speed or display mode. A long enough stream of data will eventually overtake the buffer, after which new bytes will be dropped until space is available.
Sniffer demos and documentation after the break.
I2C sniffer
The I2C sniffer is implemented in software and seems to work up to 70kHz. It’s still very beta, improvements are probably possible.
- [/] – Start/stop bit
- +/- – ACK/NACK
I2C start and stop bits are represented by the normal Bus Pirate syntax.
I2C>(2)
I2C bus sniffer, press any key to exit
[0x40-][0x40-0x40-0x30-0x56-0x77-]
I2C>
Sniffed data values are always HEX formatted in user mode. Press any key to exit the sniffer.
See here for more about the I2C sniffer in I2C binary mode.
SPI sniffer
The SPI sniffer is implemented in hardware and should work up to 10MHz. It follows the configuration settings you entered for SPI mode.
- [/] – CS enable/disable
- 0xXX – MOSI read
- (0xXX) – MISO read
SPI CS pin transitions are represented by the normal Bus Pirate syntax. The byte sniffed on the MISO pin is displayed inside ().
SPI>(1)
Sniff when:
1. CS low
2. CS high
3. All traffic
(1) >
SPI bus sniffer, any key exists
[0x30(0x00)0xff(0x12)0xff(0x50)][0x40(0x00)]
The SPI sniffer can read all traffic, or filter by the state of the CS pin. The byte sniffed on the MOSI pin is displayed as a HEX formatted value, the byte sniffed on the MISO pin is inside the ().
See here for more about the SPI sniffer in SPI binary mode.
Notes
Both sniffers use the user input buffer as a ring buffer. Any commands entered after the sniffer macro will be lost.
If the ring buffer is full, bytes are simply dropped until there’s free space. The MODE LED turns off if this happens.
As noted in the comments, pins that are normally output become inputs in sniffer node. MOSI and CLOCK are inputs in I2C sniffer mode. MOSI, CLOCK, MISO, and CS are all inputs in SPI sniffer mode.
-
Does it give a heads up when the buffer is full?
-
I am assuming that the clock (SCL) is actually input to the Bus Pirate for the sniffer mode.
The statements throughout the documentation (see http://dangerousprototypes.com/bus-pirate-manual/) state:
“Clock is always a clock-out signal from the Bus Pirate, except in the PC keyboard library where the keyboard provides a clock signal to the Bus Pirate.”
Shouldn’t this be updated to include the I2C bus sniffer mode?
Thanks
Paul -
The I2C software menu is incomplete for V3 Build 5:
HiZ>i
Bus Pirate v3 (Seeed Studio)
http://dangerousprototypes.com
Firmware v2.4-Seeed
DEVID:0×0447 REVID:0×3043 (B5)
HiZ>M
(1) >4
Mode selected
I2C mode:
1. Software
2. Hardware
(1) >1
Set speed:
1. Slow(~5KHz)
2. Fast(~50KHz)
(1) >2
READY
I2C>(0)
0.Macro menu
1.7bit address searchIt appears that macro (2) is a data dump from a specified I2C address.
Macro (3) is the I2C sniffer mode:
I2C>(3)
I2C bus sniffer, press any key to exit
[0x28+]][0x28+[0x12+0xA6+][0x28+[0x12+]][]][0x28+]][0x28+[0x11+0xCD-[0x28+[[[]][0x28+0xA0+[0xE5-[0x28+]][0x28+0x80+][]][0x28+]]Please update the menus when you get a chance.
The sniffer mode is awesome! Thanks!
-
Bus Pirate v3
Firmware v4.1 Bootloader v4.1
DEVID:0×0447 REVID:0×3043 (B5)
http://dangerousprototypes.com
HiZ>M
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC KEYBOARD
10. LCD
(1) >5
Mode selected
Set speed:
1. 30KHz
2. 125KHz
3. 250KHz
4. 1MHz
(1) >2
Clock polarity:
1. Idle low *default
2. Idle high
(1) >1
Output clock edge:
1. Idle to active
2. Active to idle *default
(2) >1
Input sample phase:
1. Middle *default
2. End
(1) >1
Select output type:
1. Open drain (H=Hi-Z, L=GND)
2. Normal (H=3.3V, L=GND)
(1) >2
READY
SPI>(1)
Sniff when:
1. CS low
2. CS high
3. All traffic
(1) >1
SPI bus sniffer, any key exists
[0x99(0x00)][0x99(0x00)][0x99(0x00)]
SPI>(1)
Sniff when:
1. CS low
2. CS high
3. All traffic
(1) >3
SPI bus sniffer, any key exists
[0x99(0x00)0x99(0x00)0x99(0x00)0x99(0x00)
SPI>Without knowing for sure I was expecting the "All traffic" sniffer to show brackes to indicate which bytes occurred inside (and outside) of CS being asserted. I imagined the output to look like this for both modes above...
[0x99(0x00)][0x99(0x00)][0x99(0x00)]
…because the data and CS behavior were both the same in each example. Instead, the output for “all traffic” removes the brackets completely. This is logical but not as helpful as I was expecting.
If I had data on the SPI outside of the CS I would expect the output for “all traffic” to look like this for example…
[0x99(0x00)]0×60(0×00)
In this way I still see all bus traffic with the added benefit of knowing which bytes occurred during CS valid and which were intended for other devices.
-
Crazy question … I just got it … USB driver installation (under WIN2K)
seems good .. COM 7 detected …. LED power on OK …. I use Hyper terminal … 115200 bauds 8N1 … carrier return …. NOTHING ?
no message ..is there a special character to tell the wonderfull BPV3a board
“hello i need you are you here” ? hi …
I didn’t find the “how to start the engine” … I only use it as an I2C sniffer
could you help me ?
Francois F1CHF
7 comments
Comments feed for this article