Intronix Logic Analyzer with I2C - what am I looking at?

[Admin]

I'm analyzing my I2C bus for my Axon (using WebbotLib) with an Intronix LogicPort logic analyzer.

I'm trying to match the signals up with my code, but I have little idea what I'm looking at (see attached). I can't seem to find tutorials for this, so I'm probably just not looking in the right spot.

D1 is the SCL (clock) and D0 is SDA (data). I'm thinking R is read, A is acknowledge, and N is 'not acknowledge' (whatever that is). So how does 3bh, 0Fh, 0Ch, 56h, etc match up to my code?

For example:

Code: [Select]

//this is in my main
BMP085_ReadTemp();

//reads from device, address 0xEE and 0xEF
int32_t BMP085_Read(unsigned char address)
{
uint8_t response[1];

if(!i2cMasterReadRegisters(&Pressure_I2C.i2cInfo, address, sizeof(response), response))
rprintf("\npressure read failed");

//combine values
int32_t val = response[0];

return val;
}

//get Temp value
int32_t BMP085_ReadTemp(void)
{
int32_t temp;

//ask for temp
i2cMasterWriteRegister(&Pressure_I2C.i2cInfo, 0xF4, 0x2E);

delay_ms(7); // max time is 4.5ms

//receive temp, UT = MSB<<8 + LSB;
temp = (BMP085_Read(0xF6) << 8) + BMP085_Read(0xF7);

return temp;
}

[Soeren]

Hi,

I'm analyzing my I2C bus for my Axon (using WebbotLib) with an Intronix LogicPort logic analyzer.

Ah, you got the good one 

I'm trying to match the signals up with my code, but I have little idea what I'm looking at (see attached). I can't seem to find tutorials for this, so I'm probably just not looking in the right spot.

Did you read the help file?
It has *some* info.

D1 is the SCL (clock) and D0 is SDA (data). I'm thinking R is read, A is acknowledge, and N is 'not acknowledge' (whatever that is). So how does 3bh, 0Fh, 0Ch, 56h, etc match up to my code?

Something goes wrong at ~Trig-175µs (among others) and that's why you get the Nack (apart from Intronix, the rest of the world calls it Nack or "Negative Acknowledge".

Could you post the LPF file?  The picture doesn't tell what's going on where it breaks (apart from the very odd clock signal, which is worth an investigation).


Perhaps try this LPF instead, just to keep to the needed lines.


Here's the meaning of the abbreviations, straight from the help file:

When commands are interpreted, they are shown as mnemonics in the waveform and state list displays. If you hover the mouse cursor over a displayed mnemonic, a more detailed description is shown. The following is a complete list of mnemonics:

S  Start
Sr  Start (repeated)
P  Stop
A  Acknowledge (Ack)
N  Not Acknowledge (Nack)
W  Write with 7 LSBs of address
R  Read with 7 LSBs of address
Wt  Write with 3 MSBs of a 10 bit address
Rt  Read with 3 MSBs of a 10 bit address
GC  General Call
HW  Hardware General Call
SB  Start Byte
HS  High Speed Mode
RP  Reset and Program command
PR  Program command
CB  CBUS Transaction
RV  Reserved Value
IV  Illegal Value

Further from the help file:

The following settings apply to I²C bus interpreters:

Name
Specify a meaningful name for this particular instance of the interpreter. This name will be displayed in the waveform and state list displays.

SDA Signal
Specify the channel which is connected to the SDA signal in your hardware. Note that from within the selection dialog you can also right-click to edit signal names.

SCL Signal
Specify the channel which is connected to the SCL signal in your hardware.

Glitch Filtering
Specify a glitch filter. The available filters correspond to the internal filters present in various speed-grade I²C devices. Note that glitch filtering applies only to interpreter results. It does not modify the acquired waveforms.

Data Format
Specify a format for the display of raw data transactions.

Interpret Command Bytes
If enabled, commands are translated to high level transactions as defined in the I²C bus specification. If not enabled, commands are shown as raw numeric values for troubleshooting purposes.

Command Format
Specify a display format for the data portion of interpreted command bytes.

Frame Synchronization is the method by which the I²C bus interpreter recognizes the beginning of the first complete bus transaction. There are two framing methods available:

I²C Start Condition
This is the preferred synchronization method. It should be used when the initial I²C start condition is contained within the LogicPort's acquired data, or if there is a repeat I²C start condition present before the data of interest. When this method is used, the interpreter will automatically find the first I²C start condition on the bus and use it for frame synchronization just as I²C hardware would do.

Cursor Position
This method is useful if the acquisition began after the initial I²C start condition had already occurred. This method allows you to "show" the interpreter the beginning of a valid data byte using a cursor. From this initial starting point the interpreter will automatically track all remaining bus transactions.

It is important to have an adequate sample rate for the I²C bus interpreter to function properly. A sample rate of 20MHz is normally high enough for all I²C devices. If you suspect that your hardware is malfunctioning because of clock glitches, you might want to increase the sample rate and turn off the interpreter's glitch filter. This will cause the interpreter to be more critical of the signals, and may help find the problem. Keep in mind that most I²C devices do contain some form of glitch filtering.

But check the clock signal as the first measure.

[Admin]

I guess I just don't have the knack for the Nack

Hi,

I'm analyzing my I2C bus for my Axon (using WebbotLib) with an Intronix LogicPort logic analyzer.

Ah, you got the good one 

Nah . . . someone loaned it to me last night. I don't have it now, though, but I'll meet the guy again next week. My problem has been resolved so I'll put this on the back-burner for now until it comes up again.


Everything looked like it was measuring properly, but I just didn't know what all those 3bh, 0Fh, 0Ch, 56h thingies meant. I assume they are hex values or something, representing data somehow.