Just thought I'd mention that I figured out what was going on. My bus was running a little fast and the BP was unable to keep up with it.
I did get a copy of the source and compiled in some 10us timing markers to see how the BP was performing. It clearly was sampling all over the place and not keeping up with the clock and data. I also changed the code from a software loop to an ISR and that didn't help much either. In fact I think it got worse.
Then I realized my bus was actually running at 185khz. Backed it down to 100khz and the BP could read the bus and keep up just fine. I ran it for about 7 hours capturing about .25 million frames and no errors.
So that was it. The BP is fast enough to be a software sniffer for 100k I2C, but not faster at 185k. And definitely not at 400k or higher. The ISR wasn't better than the tight while loop. Mainly because of the ISR overhead I would guess. If the v4 has a significantly faster clock speed it can probably do better than the v3. I ordered one so we'll see.
Is this the best place for support on the BP and its firmware? Not getting much of a response.
I've done some more analysis on this problem. I wrote a python program to drive the BP in binary mode to capture data from the I2C sniffer mode. Basically it watches for the apparent missing byte and uses AUX to trigger an external logic analyzer or o-scope. That part works fine. With buffering there is about a 20ms delay between the missed character and the trigger.
Triggered captures on both the logic analyzer and a mixed signal o-scope all agree that no clock or data is missing while the BP apparently misses the data byte. Protocol decoding on both the logic analyzer and the scope are also right on, showing proper full decoded frames while the BP again shows a missed byte. The analog side of the scope also shows good signal levels, minimal slew and rise times, etc. A little noise and ringing but nothing unusual.
I have also looked at the code for the I2C sniffer mode and nothing surprising there. It's a software sniffer as one would expect. Running in a tight while loop with a few external calls. Basically just servicing the output buffer and checking for the termination character. I haven't figured out yet if there are any other interrupts getting serviced.
Maybe the sniffer mode just can't keep up with the clock and data at 100k
I'd love to figure out how to recompile the firmware so I can output little 1us marker pulses on the aux to see if there are any timing issues. That's all I can think of right now
Is that a win32 console app? One thing you can do is set the console screen buffer size to a large number to retain more of the data. But if you need thousands of lines that probably won't work. You can also alter the SPIsniffer code to log directly to a file. Should be an easy hack.
I think I posted this in the wrong place originally. Sorry for the dp.
Just got my first BP and by all indications it is working great. One of the first things I did with it was monitor the I2C bus on a project I have been working on. Basically several different PIC based boards communicating with each other. And I see an anomaly with the I2C data sniffed and captured by the BP. I am hoping someone can help me understand what is happening or how to fix it.
The new BP is v3b, firmware 5.10 (r559). From Seeed not Sparkfun
The PICs basically send a short command and update frame (the master) and the slaves respond to the subsequent read with a similar status frame. The I2C data rate is 100kbps. 5v PIC architecture. 4.7k pullups. All of this is working, and has been for a long time. What I am trying to do is monitor and perform a long-term data capture for analysis.
This is a normal captured sequence. There are two slaves currently in the circuit.
The master first writes 5 bytes to addr 01 (0x02 in the above), then reads from the same address. Then continues with a write to addr 02 (0x04 in the above) and then reads from the same address.
This is abnormal and is what I get out of the BP in I2C sniffer mode about 40-50% of the time on average.
It's always the last byte (I think) of the first sequence that is not captured by the BP. The second, third and fourth sequence are always spot on. There is typically a delay of between 100ms and up to 400ms between the last sequence and the start of the next new four sequences. So the sequences basically run like ||||--------------------||||-------------------||||------------etc.
I also connected a decoding logic analyzer to the same setup to compare results. Sampling at 24mhz I get very clean I2C clock and signaling and perfect decoding of all the data sequences. On the decoding logic analyzer I don't ever see the apparent lost byte on the first sequence like the BP often shows.
I know this is a lot to absorb and a funky problem but I hope someone will be able to offer some insight or suggestions.
I can reproduce the issue at will and can provide additional data plus data from the logic analyzer if that will help at all.
Just got my first BP and by all indications it is working great. One of the first things I did with it was monitor the I2C bus on a project I have been working on. Basically several different PIC based boards communicating with each other. And I see an anomaly with the I2C data sniffed and captured by the BP. I am hoping someone can help me understand what is happening or how to fix it.
The new BP is v3b, firmware 5.10 (r559). From Seeed not Sparkfun
The PICs basically send a short command and update frame (the master) and the slaves respond to the subsequent read with a similar status frame. The I2C data rate is 100kbps. All of this is working, and has been for a long time. What I am trying to do is monitor and perform a long-term data capture for analysis.
This is a normal captured sequence. There are two slaves currently in the circuit.
The master first writes 5 bytes to addr 01 (0x02 in the above), then reads from the same address. Then continues with a write to addr 02 (0x04 in the above) and then reads from the same address.
This is abnormal and is what I get out of the BP in I2C sniffer mode about 40-50% of the time on average.
It's always the last byte (I think) of the first sequence that is not captured by the BP. The second, third and fourth sequence are always spot on. There is typically a delay of between 100ms and up to 400ms between the last sequence and the start of the next new four sequences. So the sequences basically run like ||||--------------------||||-------------------||||------------etc.
I also connected a decoding logic analyzer to the same setup to compare results. Sampling at 24mhz I get very clean I2C clock and signaling and perfect decoding of all the data sequences. On the decoding logic analyzer I don't ever see the apparent lost byte on the first sequence like the BP often shows.
I know this is a lot to absorb and a funky problem but I hope someone will be able to offer some insight or suggestions.
I can reproduce the issue at will and can provide additional data plus data from the logic analyzer if that will help at all.
