Bus Pirate I2C, SPI sniffer updates

Posted on Thursday, November 5th, 2009 in Bus Pirate by Ian


See the latest version in the documentation wiki.

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 bus sniffer, press any key to exit

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 ().

Sniff when:
1. CS low
2. CS high
3. All traffic
(1) >
SPI bus sniffer, any key exists

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 (fixed due to the buffering system), the byte sniffed on the MISO pin is inside the ().

Press ‘r’ to restart the sniffer without returning to SPI mode (new in v5.1). Press any other key to exit.

If the sniffer can’t keep with the SPI data, the MODE LED turns off and the sniff is aborted (new in v5.1).

See here for more about the SPI sniffer in SPI binary mode.


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.

This entry was posted on Thursday, November 5th, 2009 at 2:41 pm and is filed under Bus Pirate. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

11 Responses to “Bus Pirate I2C, SPI sniffer updates”

  1. James says:

    Does it give a heads up when the buffer is full?

  2. Ian says:

    No, but it should. I’ll have it flip the MODE LED off.

  3. Paul says:

    I am assuming that the clock (SCL) is actually input to the Bus Pirate for the sniffer mode.

    The statements throughout the documentation (see 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?


  4. Paul says:

    The I2C software menu is incomplete for V3 Build 5:

    Bus Pirate v3 (Seeed Studio)
    Firmware v2.4-Seeed
    DEVID:0x0447 REVID:0x3043 (B5)
    (1) >4
    Mode selected
    I2C mode:
    1. Software
    2. Hardware
    (1) >1
    Set speed:
    1. Slow(~5KHz)
    2. Fast(~50KHz)
    (1) >2
    0.Macro menu
    1.7bit address search

    It appears that macro (2) is a data dump from a specified I2C address.

    Macro (3) is the I2C sniffer mode:
    I2C bus sniffer, press any key to exit

    Please update the menus when you get a chance.

    The sniffer mode is awesome! Thanks!

  5. Ian says:

    Hi Paul – You’re correct about the clock being input in sniffer mode.

    >Firmware v2.4-Seeed

    It looks like you have v2.4 of the firmware, though. The sniffer was an undocumented alpha feature at that time, an update to v3 should fix the menu and implement the latest features.

  6. Mark says:

    Bus Pirate v3
    Firmware v4.1 Bootloader v4.1
    DEVID:0x0447 REVID:0x3043 (B5)
    1. HiZ
    2. 1-WIRE
    3. UART
    4. I2C
    5. SPI
    6. JTAG
    7. RAW2WIRE
    8. RAW3WIRE
    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
    Sniff when:
    1. CS low
    2. CS high
    3. All traffic
    (1) >1
    SPI bus sniffer, any key exists
    Sniff when:
    1. CS low
    2. CS high
    3. All traffic
    (1) >3
    SPI bus sniffer, any key exists

    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…


    …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…


    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.

  7. F1CHF says:

    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 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

  8. toddkrein says:

    On the V5.5 firmware, what is the maximum I2C sniffer rate? I’m trying to track the accesses on a bus running at 93kHz, and it’s giving me a lot of garbage… Selecting 100kHz speed vs. 400kHz speed on the mode select doesn’t seem to help.

    Using the BP to read and write to the in-circuit EEPROM works fine, so it’s not likely a signal integrity issue…

    • Ian says:

      Hi Todd – that latest firmware has an updated sniffer that is good to almost 100khz (not sure the exact version). You’re just about there, so it might get a little hairy. You could also try the logic analyzer mode which is good to around 1mhz, Jawi’s latest SUMP client has I2C decoding.

      The speed setting in the I2C mode only effects the output, not the sniffer speed.

  9. ben says:

    Is there a link with the latest firmware for each of the bus pirate versions?

    I could use an i2c sniffer, but only have an older v2go board. Not sure what firmware is on it, let alone if it could even support the V5.5 that the sniffer is implemented on.

Leave a Reply

Notify me of followup comments via e-mail. You can also subscribe without commenting.

Recent Comments

  • Max: Seems like an unexpectedly violent way to remove the chip indeed. A hot air station should of course do the job just fine, but in...
  • jose: Part removal described here is pure butchery, the cheapest hot air station will do a fast and clean job removing the QFP, heat air to...
  • Cody: Yes please
  • Marko: armature -> amateur
  • Crawford: Dibs,