I2Csniffer appears to fail at 400KHz

July 12, 2011, 08:20:37 am

Ian,
just got BP Version v3b and hooked it up to a known PIC24F system using I2C in a known test environment. The test system allows me to send a single address (read or write), a single register value, and a single value to either read or write from that register. It has been tested with a LogicProb and works great. So I wanted to verify that the BP V3b could sniff the known traffic pattern. Here is my session:

i
Bus Pirate v3b
Firmware v5.10 (r559) Bootloader v4.4
DEVID:0x0447 REVID:0x3043 (24FJ64GA002 B5)
http://dangerousprototypes.com
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. 2WIRE
7. 3WIRE
8. LCD
9. DIO
x. exit(without change)

(1)>4
Set speed:
1. ~5KHz
2. ~50KHz
3. ~100KHz
4. ~400KHz

(1)>4
Ready
I2C>(0)
0.Macro menu
1.7bit address search
2.I2C sniffer
I2C>(1)
Searching I2C address space. Found devices at:
0x18(0x0C W) 0x19(0x0C R) 0x90(0x48 W) 0x91(0x48 R)

I2C>(2)
Sniffer
Any key to exit
[0x18+0x92+0x91-][0x18+0x02+0x93-0x1A-0x80+0xB7+0x00-0xD4-][0x18+[0x12+0x73-0x09-]][0x18+[0x12-0x01-][0x18+[0x19+0x00+0x00+0x00+0x02+0x01+][0x19+0x00+0x00+0x00+0x00+0x78+]

What I had done in the GUI to the 2nd PIC24F was ask it's I2C to WRITE an address 0x0C for register 0x80 and the result returned was 0x00 each of three successive attempts. While I didn't have the LogicPort or the Tek scope on the system when I took this data, I have done it hundreds of times in the Lab and know that I WRITE to 0x18 and WRITE to value of 0x80 and I READ back a single byte of 0x00.

So I see in the three instances above the [0x18...] as the base address write, but all the other data appears to be random. I note that the [] can get out of order. I assume this would mean that my data read/writes are just too fast for the hardware logic in I2Csniffer?

In a second test using the same GUI that I know and trust, I WRITE to address 0x18 (base address 0x0C), WRITE out a register value of 0x0e, and I should get a value in the range of 0x20 to 0x55. What the I2Csniffer returned to me was:
[0x30-[[0x19+][0x30-[0x19+][0x30-[0x19+]
for three succesive attempts.

I think this again points to the problem that the sniffer cannot keep up with the 400KHz data flow. Sadly I don't have a way to throttle down the I2C data transfers. Can you suggest any tests I can do to be sure the I2Csniffer could see these simple 3 byte transactions?

ANOTHER QUESTION: where can I find the source code for version v5.10 that I have? I do not see it on the wiki.

LAST QUESTION: I want to modify the I2Csniffer code. If I make changes to those hardware routines, do I just use the V4.4 bootloader and then new system will be loaded into the BP? I want to "gut" a huge amount of V5.10 out of the PIC and use RAM to store successive reads of SDA and SCL so that I can view what happens on the I2C bus when sampled at 800KHz rates after the first SCL transition happens. If I get rid of SPI and other protocols, will the system still jump to the I2Csniffer when I do a:
(2)
for the I2C mode?

My ultimate goal is to turn I2Csniffer into a bus qualifier system where I could sniffer, for example, to see a WRITE to address 0x18 followed by a WRITE to 0x80 followed by a READ of a byte within a range of values. When I find this condition TRUE, I turn on a GPIO line which is used as a trigger for our 8K samples of the logicPort. I would be using the BP as a logical "trigger" device to search for very specific types of I2C bus activity before turning on a GPIO line to trigger an external device. This is needed by a great number of designers to capture what is on the I2C bus during a specific transaction that they hardware code into the BP. Has anyone done this with the BP yet?
Ted Cooper

Re: I2Csniffer appears to fail at 400KHz

Reply #1 – July 12, 2011, 01:45:48 pm

I believe 400k is too fast for BP sniffer. I was successfully sniffing traffic up to 200k and not over .. (faster then that and you start getting read errors). if you need to sniff 400k I suggest logicshrimp http://dangerousprototypes.com/docs/Log ... c_analyzer

it has 256k samples memory and jawi's tool works super cool to decode the i2c

Re: I2Csniffer appears to fail at 400KHz

Reply #2 – July 12, 2011, 02:27:02 pm

The code is not in the Wiki but in the SVN: http://code.google.com/p/the-bus-pirate/source/checkout

The sniffer cannot cope with high speeds. Several people have optimized the sniffer code, but it can't be very much faster then it is already. The only optimalization i see is to buffer the bytes and spit them out after a bufferoverflow. However i question the usability of this approach. The solution arhi says is I think the best way to do it, the same functionality has the OLS at a higher sampling rate, but both can easily cope with 400KHz I2C. Have you ever tried the buspirate LA function? http://dangerousprototypes.com/docs/Bus ... _with_SUMP

If you remove the other protocols you get more flash memory and almost no extra RAM. In the source there is a general 4k buffer which you can use for buffering data. If you just leave I2C (and raw2wire which is mandatory for I2C) you still have (2) for I2C sniffer.

Re: I2Csniffer appears to fail at 400KHz

Reply #3 – July 13, 2011, 10:45:54 am

Hi TJ,

It looks like my last test got close to 100KHz. I think it will be hard to sniff 800KHz in software on the bus pirate. The internal clock is 16MIPs, so 800KHz only gives 20instructions between each transition to service the interrupt, do something, then return from interrupt. Somewhere in there you need to service the UART to dump to the PC. We currently use a 4096byte buffer for the sniffer, it is usually a speed problem not a memory problem that limits performance.

The latest source can be found in the Bus Pirate SVN at google code. If you need any help working with it please let us know. It's always fun when someone else trys out the source.