Keysight MSOX3034T takes on I2C bus decode challenges

In this post I relate my experiences using the Keysight MSOX3034TMSOX3034T and a Tektronix MDO4000 series instrument to decode I2C data packets.  The use case I explore in this post posed some measurement challenges, mostly due to fairly lengthy delays between packet transmissions, but the MSOX3034TMSOX3034T rose to meet the challenge and delivered the measurements I needed to take.  I will highlight some interesting user interface differences between the Keysight and Tektronix approach to slow speed bus decode. First, to give context to the measurements, I will provide some background on the use case.

I2C use case

I2C, or Inter-Integrated Circuit, is a low speed two wire digital communications protocol used by many chip manufacturers to get data into and out of their devices. The bus itself is composed of two signal wires: a serial data line (SDA), and a serial clock line (SCL).  A master device can be connected to many slave devices sharing the same SDA and SCL bus lines.  The master sends out an addressed packet of information that all slaves listen to, but only the addressed device responds.  In this use case I am looking at I2C data packets in a small data logger system.  The master in this system is a PIC18F4520 microcontroller.  Listed below in the table are the four slave I2C devices in the system, along with their 8 bit (R/W bit included) I2C addresses.

The block diagram below shows how the four I2C devices are connected to the PIC microcontroller.  Note the two pull up resistors (R13 and R14) are required to allow proper operation of the I2C bus.

Firmware in the data logger allows the user to set up data logging missions that take samples of ambient temperature and illumination at user defined intervals.  Samples can be stored in the I2C EEPROM for later retrieval, or they can be sent immediately to an RS-232RS-232 serial port for upload to a computer. I used the Keysight MSOX3034TMSOX3034T to examine I2C data packets moving through the system.  For comparison purposes I examined the same data traffic using a Tektronix MDO4104-3.

One of the great advantages of modern oscilloscopes over legacy CRT oscilloscopes is the availability (from many vendors) of built-in automatic bus decode.  To truly appreciate how wonderful this feature is you need to spend several hours doing manual bus decode.  This not-ever-fun activity involves single sweeping a set of packets (clock and data), then scrolling through the record following clock edges and noting if the data line is high or low, writing down your observations in binary, then finally converting those observations into hex.   To have your oscilloscope do all of this for you in real time, or very near real time, is a great time saver.  Many serial protocols are in contemporary use.  Most oscilloscopes can decode several protocols, in some cases only with purchase of a license  Below is a table showing the protocols that can be decoded by the MSOX3034TMSOX3034T and the MDO4104-3. The [*] symbols in the MDO4104-3 column indicate decode capabilities enabled in my 'scope.  The Road Test MSOX3034TMSOX3034T arrived with all of the listed decode capabilities enabled.

Both oscilloscopes can perform fully automatic I2C and RS-232RS-232 data decode. The two vendors approach this task differently.  The Keysght instrument has a custom Application Specific Integrated Circuit (ASIC) dedicated to serial bus decode.  This approach results in very fast decoding of captured waveform records.  The Tektronix instrument uses firmware to decode waveform records.  This can result in fairly slow decoding, especially if the acquisition is set to 20 M Samples/channel. Although it may seem obvious that a dedicated ASIC is a superior solution, you will see later in this blog that, in some circumstances, the Tektronix implementation offers some advantages.

Set up of both instruments to capture I2C signals is very straightforward.  I used two of the analog channels, one for SDA,the other for SCL, but could have also used two of the mixed signal digital inputs. The first I2C signals I looked at are generated following boot up of the data logger.  At this point in the logger set up routine the user is asked to confirm or change the Real Time Clock (RTC) settings as shown on the display image below.

An infrared (IR) receiver on the data logger is the primary means of accepting user commands.  The data logger firmware has been written to detect and decode TV/VCR codes emitted by any SONY capable remote control.  The firmware is in a loop at this point checking for two things: RTC interrupts and activity on the IR receiver. The RTC generates an Interrupt Request (IRQ) once per second.  The firmware responds to this signal by reading the contents of the RTC and transferring the contents to the LCD. After the display is updated the firmware looks for valid SONY IR code activity on the IR receiver.  If PLAY is detected, the firmware accepts the current RTC values and proceeds to the next set up step.  If STOP is detected the firmware prompts the user for new RTC values.  While waiting for the user to press PLAY or STOP the I2C bus will be composed of a brief burst of communication with the M41T81 RTC chip once every second.

Let's capture some I2C signals

I set up both 'scopes to allow confirmation of this expected activity.  That required a time base setting of 200 ms/div to capture more than one second of bus activity.  Both 'scopes were set up to trigger on an I2C Start condition (SDA falls while SCL is high).  The images below show what the two instruments display under these conditions.

Good.  As expected the burst of I2C activity occurs about once per second.  If we speed up the time base to 400 us/div we can see what is happening within the once per second burst.  The images below show the packet contents on both 'scopes.

Time to decode some I2C signals

At this point, if we were working with an old CRT storage 'scope or a less capable digital 'scope we would have to resort to manual decode methods to extract I2C bus activity.  Thankfully, both of these fine instruments offer automatic I2C bus decode. It is a simple matter on both instruments to set up bus decode by defining the two input signals, setting up trigger thresholds, selecting an address display mode (7 bit which excludes the R/W bit, or 8 bit which includes the R/W bit) and voila, decoded I2C data traffic appears beneath the waveform traces.  Well, almost.  Something odd happened with the Keysight I2C decoded data. This is explained below.  There is also a caveat on the Tektronix data decode.

First, the Tektronix caveat. You may notice that the Tektronix screen capture looks a little rough, especially on the I2C clock.  This is a consequence of reducing the acquisition buffer size to 100 k points, which reduced the sample rate to 25.0 MSa/s.  I chose to reduce the acquisition buffer size to 100 k samples to allow the software bus decode to keep up with new data bursts that arrive once per second.  If the acquisition buffer is made larger, signal resolution improves dramatically, but the software decode in the Tek scope takes much longer to complete and the I2C decode display lags behind resulting in a lot of missed decodes.  With a 20 MSa buffer size, for example, the sample rate jumps to 5.00 GSa/s, which provides very rich signal detail indeed, however, at best, the software based I2C decode only manages to update every 8 seconds. The Keysight ASIC hardware based decoder had no problem decoding the acquisition buffer in essentially real time.  No packets are missed at all. In this example the Keysight ASIC hardware decode takes the win over Tektronix software decode.  However, the battle is still on and there are more skirmishes to be decided.

The next skirmish involves display of the decoded I2C data exchange.  A bit of clarity is needed on what is contained in the exchange before we proceed to examine how each vendor goes about displaying the I2C data exchange.  The code snippet below shows the I2C commands that are being executed during the exchange seen on the 'scopes.

The first i2cread command starts by writing a register pointer ($F) to the M41T81 chip. In the M41T81, register $F is the flags register.  Bit 6 is the Alarm Flag (AF) within the flags register.  Reading register F clears the AF bit..  The actual exchange on the I2C bus during execution of the first i2cread command will look like:

Once this exchange completes, the IRQ pin on the M41T81 will go high and contents of the RTC seconds, minutes, hours, day, date, month, and year values can be transferred from the RTC chip to the PIC. This transfer happens during the second i2cread command. The important thing to note about the second i2cread command is that there should be seven bytes of data transferred from the M41T81 to the PIC, thus the [str RTCtime\7] syntax in the second command.  The exchange on the I2C bus for the second command will look something like this:

This is where the Keysight 'scope does something rather odd.  We are expecting a total of 14 bytes to be exchanged between the PIC and the M41T81 during execution of the two i2cread commands.  The Tektronix 'scope indeed shows 14 bytes exchanged in the decoded display beneath the two I2C signals.  However, for whatever reason, the Keysight 'scope shows 10 bytes exchanged in the decoded display beneath the I2C signals.  The last four bytes are truncated.  Did the Keysight 'scope not capture the entire exchange? I set up both 'scopes to count and display the number of rising edges on the I2C Clock signal in their acquisition buffers.  Both counted 130 rising edges. Hmm, so where is the rest of the I2C data on the Keysight display?  Next, I turned on tabular displays of the decoded data on both 'scopes.  Interesting, now Keysight shows all 14 bytes, as does Tektronix.  See the screen captures below.  However, new oddities have appeared.  Why don't the time stamps agree between vendors and why don't both 'scopes agree on detection of missing acknowledge events? That is a problem to work out at a later time.  Right now, I'd like to focus on the truncated I2C decode on the Keysight display.

What I discovered after some experimenting is that the Keysight on-screen I2C decode is very dependent on the time base setting.  If the time base is set to a very slow speed, causing the traces to be bunched up, only a few bytes of decode are displayed.  If the time base is sped up to spread out the signals, more bytes are displayed in the decode trace.  See the effect at 260 us/div and 2 ms/div below.

In this skirmish Tektronix comes out ahead.  Sorry Keysight, but It is just plain confusing to see all of I2C signals captured on the screen with a truncated decode display underneath.  Tektronix uses a dynamic content representation method to show I2C decode details.  A clever combination of alphanumerics, colors, and symbols help convey decoded information .  The way decoded information is displayed changes depending on time base setting. In the Tektronix screen captures above taken at 400 us/div, all 14 bytes of I2C communication are displayed under the signal traces. At this time base setting display space is at a premium, so colored outlines and brackets help convey detail without inserting additional characters.   A yellow outline indicates an address is on the bus, teal outline indicates data is on the bus.  A green [ in front of a byte indicates a start or restart condition.  A red ] after a byte indicates a missing acknowledge. As time base speed is decreased and the waveform spreads out, I2C information becomes more textual.  Eventually whole words are used to describe bus activity.  See the example below at 100 us/div where each address is described as Addr[W] or Addr[R] and data is identified clearly.

Conversely, Keysight relies mostly on alphanumeric symbols and a little bit of color to convey decode detail.  For example where Tektronix decodes a restart read from address D1 with a successful acknowledge as [D1 in a yellow box, Keysight decodes the same event as SD1Ra,which clearly takes up more space on the screen. So, yes, I prefer the way Tektronix handles on-screen I2C bus decode.  One more skirmish to settle, then on to RS-232RS-232 decode challenges in the next blog post.

Using event search functions

Both scopes have search functions that will go through an acquisition record and place markers at specific points depending on user entered search criteria.  You can then use forward/back arrow buttons to jump between marked events.  There are interesting differences in how the two vendors implement the search function in the I2C use case described here.  The search experience on the Keysight begins with a press of the physical front panel "Search" button.  A text prompt appears at the bottom margin of the screen advising "To search on Serial, you need to turn on Serial Decode and Lister.  Press[Serial}>Lister>Window."  Well serial decode is already on, and isn't it simpler to just use the touch screen to activate the pull down "Lister" window?  And better yet, how about coding the firmware to do all of this automatically when the user presses the "Search" button.  At any rate, I set up the Keysight to search for any address activity, read or write.  The 'scope placed four white triangular markers on the waveform.  The markers appear to be positioned at the beginning of each address event. The search experience on the Tektronix  also begins with a press of the physical "search" button.  Once parameters are entered, search is activated with a soft key and four triangular markers are placed on the waveform, albeit at different locations.  Tektronix marks the end of search events.  This may explain the difference in time stamps noted earlier. The two search screens set up on identical signal streams are shown below.

To this point the user experience is about the same in terms of effort to establish search criteria and obtain markers on a live data stream.  The Tektronix screen is a little cleaner because it does not impose the list view on the top half of the screen.  The next exploration I attempted immediately separated the two instruments into a "preferred" and a "not preferred" category.  Now that the markers are established I wanted to skip through the record to get a better view of each event. On the Tektronix instrument, as soon as you push the forward or reverse arrow, magnification is turned on, the time base is adjusted to view the search event and the following byte, and the search event marker is centered on the magnified view.  All very nice.  You can then skip forward or backward through the live data to look at specific search events. On the Keysight instrument when you push the forward or backward search arrow, a text string appears reminding you that "The navigate buttons are used when acquisitions are stopped."  Oh, so I can't skip through a live signal stream to look at specific search events?  Ok.  So I run a single acquisition, then use the navigate buttons. I'm still deciding if I like what happened next. The time base changes to zoom mode, but it changes to a different zoom ratio for every marked event.  The 'scope adjusts the zoomed time base to fit in the search event and subsequent bytes associated with that event.  So, for the first address marker the time base is set to 61.45 us/div to show the address and the subsequent byte.  For the forth marker the time base switches to 126.9 us/div to show the address event and the subsequent seven bytes.  I think the idea is be helpful by showing everything associated with the marked event, working on the assumption you are of course going to be interested in everything associated with the event you were searching for, rather than just the event itself.  Not sure if I agree with that assumption.  The bigger issue for me is that I can't navigate through markers on live signal data.  Tektronix wins this skirmish.

Conclusion

The Keysight MSOX3034TMSOX3034T was able to acquire and display the I2C signal information I was interested in.  The Tektronix MDO4000 was also able to accomplish the I2C signal investigation task. Is one better at this task than the other?  A definitive argument for one over the other is hard to find.  It may come down to a matter of personal preference.  I have been using the MDO4000 series for 8 years so I feel very comfortable with its user interface, its capabilities, and its limitations.  When it comes to I2C signal capture and decode, Keysight instrument operation is quite different from Tektronix operation. I find the Tektronix approach simpler and more intuitive.  The Keysight approach is more restrictive (no live signal search) and it requires adopting a slightly different perspective on signal acquisition.  The touch screen on the Keysight 'scope does have a certain appeal.  As mentioned in a previous blog I often go to touch the Tektronix screen to perform an operation, forgetting that it is not touch enabled.  This impulse shows me that I prefer to interact with signals using on-screen touch.  However, touch has to work very well to truly be a time saver.  So far I'd say the touch interface on the Keysight 'scope gets a B+ in terms of reliable operation.  More to come on my experiences with the touch interface in future blog posts.

Next

In my net blog post I look at more slow speed signal challenges that combine I2C with RS-232RS-232.  Oh boy, there were some challenges!

All the best,

Mark A.