I am planning to use my bus pirate to sniff the SMBus on P4 motherboard. Just wonder if any of you have done a similar thing or any pointers before I may accidental fry something or being lost....
Just to confirm, SMBus on PC motherboard are 3.3V?
Will Bus Pirate be fast enough/capable to capture the traffic?
Thx
The current Bus Pirate firmware only has an SPI sniffer. The I2C sniffer is still highly experimental and isn't very fast. Is SMBus limited to the I2C speeds (100K, 400K, 1M)? Someone is working on an I2C slave mode that might eventually be a component of a high-speed sniffer. A logic analyzer is probably the best tool for high-speed bus capture.
I imagine SMBus speed and voltage on motherboards depends on the chipset and architecture. A lot of new stuff is 1.8 or 2.5volts. If you're just sniffing, then it wouldn't matter because the Bus Pirate is only watching and not contributing. If you were trying to interact with it as a master, you'd just connect the Vpullup line to whatever the proper supply voltage is because I2C (SMBus) is an open collector bus.
SMBus 1.1 is limited to speeds of up to 100K, I believe the 2.0 spec supports speeds up to 400K
I'm also interested in trying to get the I2C bus sniffer working for a project, and so far it seems to be most of the way there. In my case the bus being analyzed is running at 100 KHz
I'm actually trying to use the bus pirate to sniff SMBus traffic between a battery and charger module. The data seems partly right, in that the vast majority of fresh start conditions show the expected address bytes following. I'm wondering though about the bytes that follow. Just looking at the output from the bus the start & end conditions don't seem to group data into valid chunks for the protocol being used between the battery and charger.
My suspicion is that the sniffer catches the first byte, but then gets tied up when transmitting the decoded data over the serial port, missing the proper sequence of bytes that follow. Anyone else know more about this in the bus-pirate firmware?
Just an update, I've managed to verify that the sniffer consistently reads the first two bytes following a start condition correctly, and then garbage following. I'm guessing that this is due to the serial baudrate being limited to 115200, when monitoring SMBus at 100000 (100K).
Looking at the specs on the FTDI chip it should be able to support baud rates up to 1M baud, it's just the firmware on the pic that's capped out at 115200. If I can throw together a patch for the c code to support higher baud rates, can anyone compile it to a hex image for me?
@aphoticjezter - I think that's the problem too, but there's also a problem detecting stop bits.
One way you can increase the speed is change the Bus Pirate display mode to raw and then have your terminal (try Hercules from HW-group.com) show the HEX equivalent of the raw byte values. Then it doesn't have to shove 5 or 6 ASCII bytes up the wire for every byte snooped. You'd need 10x the snooped bandwidth to see the data in real time with ASCII output.
Here's the I2C sniffer code:
http://code.google.com/p/the-bus-pirate ... /I2C.c#234 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/I2C.c#234)
If you have working I2C hardware (B4 or later silicone), it might be better to implement this in hardware (if possible).
I can compile any patch, no problem.
Humm. I wonder if the recent "Bus Pirate logic analyzer mode" in V3 firmware will help... Time to spend some time and play with it again...
Please let me know how it goes.
OK, finally after a while... get the Java Applet to go.
Now, I just need to get some signal going... (hint: it would be nice if there is some "self test" mode where user can hook up jumper to test the logic analyzer mode with some internal signals...)
Will try to do that as soon as I have some slacking time... ;)
(BTW, for those who is looking for the Logic Analyzer Mode, see http://dangerousprototypes.com/2009/11/ ... #more-2070 (http://dangerousprototypes.com/2009/11/03/bus-pirate-logic-analyzer-mode/#more-2070))
OK, so far I have tried a few runs.. but started to get annoyed but the app...
I have to keep hitting "Capture" a few times to get it to run. Often I see this in my DOS screen when it fails to capture....
Attaching to: COM8 (115200bps)
Run started
Device ID: 0x534c4131
11000000 00000000 00000000 00000000 00000000
11000001 00000000 00000000 00000000 00000000
11000010 00000000 00000000 00000000 00001000
10000000 01100011 00000000 00000000 00000000
10000001 11111111 00000011 11111111 00000011
Flags: 10
10000010 00000010 00000000 00000000 00000000
Run aborted
And the Pop up will show
(http://http://img691.imageshack.us/img691/3295/clipboard01rb.th.jpg) (http://http://img691.imageshack.us/i/clipboard01rb.jpg/)
Wrong screen capture above.. oops.
Attaching to: COM8 (115200bps)
Run started
Device ID: 0x534c4131
11000000 00000000 00000000 00000000 00000000
11000001 00000000 00000000 00000000 00000000
11000010 00000000 00000000 00000000 00001000
10000000 01100011 00000000 00000000 00000000
10000001 11111111 00000011 11111111 00000011
Flags: 111010
10000010 00111010 00000000 00000000 00000000
Run aborted
It sees the Bus Pirate and accepts it as a SUMP device.
Does the error happen as the data is transferred back to SUMP? I think there is an issue with a slight delay in the USB->serial part that makes SUMP think there's no more data.
I used portmon to look at the traffic, and after a few bytes sometimes there's a read timeout. SUMP takes that to be an error, but really it's latency from the USB->serial driver.
Changing the minimum read timeout (msec) in the FTDI driver setting to at least 4000 (device manager->ports->COMx properties->port settings->advanced in Windows) cleared any remaining problems on my system. Another way is to decrease the latency timer, but that hurts performance a lot.
Ideally, SUMP would have a simple text .ini file with settings for things like read timeout (one byte, really?), device types, and clock divider, so this stuff is easier to address. But that's not how it's built (yet)...
ian, an update. I hacked the binary file to change the bitrate for one of the speeds to 230400 (maybe support for this and higher speeds should be added to the firmware as the ftdi chip seems to handle them), and I also used RAW mode as suggested. So far I seem to be reliably sniffing the traffic, sorry I have no patches for the serial baudrate at this time tho.
I'll try to roll a high baud-rate option into the v3.0 firmware release.
@aphoticjezter - Would yo try again with the latest nightly compile from SVN? I updated the I2C sniffer and added a 4096byte ring buffer so it should work despite the UART bottleneck:
http://dangerousprototypes.com/2009/11/ ... r-updates/ (http://dangerousprototypes.com/2009/11/05/bus-pirate-i2c-spi-sniffer-updates/)
Regarding the request for "internal" signals for testing analyzer mode, stray power-line signals toggle the data lines fine for me by touching my fingertip to the MISO, MOSI, etc. pins. In my case I get nice 60 Hz waveforms. Even at 1 MHz sample rate, you only have to hit capture 2 or 3 times to get zero-crossings to toggle the I/O lines. At 10 KHz you get lots of toggles.
Hey Iain, for some reason the v3 firmware doesn't let me use raw mode when using the i2c sniffer. I'm pretty sure that I could set it using the patched version I had... but I haven't confirmed that yet. If I get the chance I'll confirm it, but does that sound like a possible regression to you?
@aphoticjezter - I added a 4096 ring buffer so it can keep up with fast traffic longer, but I only created a buffered HEX function and not one for DEC/BIN/ or RAW. RAW should be easy enough, I'll try to add it to the next release.