Scan I2C bus for any present device - the easy way!

Ikalogic blog

Using a ScanaQuad logic analyzer and pattern generator, powered by the latest ScanaStudio V4.0, there are really a lot of things you can do. Today let’s look at one application which you may encounter in many different situations in the life cycle of an electronics product. Often we design printed circuit boards with many (sometimes dozens) of I2C devices (like temperature sensors, ambient light sensors, IMU, EEPROM, RAM, and the list goes on!).

SQ200 Logic Analyzer I2C scanner

In such a scenario, one often needs to quickly check if all devices are responding correctly (i.e. that they are acknowledging their address call on the I2C bus).

We have written a small add-on script for SQ logic analyzer device that let’s you do just that! Meet the I2C scanner script:

I2C scanner script

How the I2C scanner actually works

This add-on script offer two features:

  • A signal builder feature
  • A signal decoder feature

So here is how it works:

  1. Using the signal builder feature, you build a long series of I2C address calls (128 addresses actually, minus the reserved and invalid I2C addresses).
  2. Then, you setup the SQ logic analyzer in mixed mode (Capture + Generate) and set the I2C lines in open drain mode. Optionally, you can activate internal 10K pull up resistors inside the SQ device front end (see picture below). Config IO in mixed mode
  3. Run a Generate/capture sequence with your SQ device
  4. Decode captured signals and open the hex view.

The decoder function of this script is very simplistic and it’s main (and only) purpose is to like the addresses of I2C devices present on an I2C bus as in the example below:

I2C scan example


How to open older ScanaStudio files

Ikalogic blog

NOTE: We’re currently working on bringing back support to older ScanaStudio files.

Along the years, ScanaStudio software has drastically changed, so did our experience in handling the evolution of the features of the software.

We always try to support older files, and the further we move, the more we try to be backward compatibly. However, at some point in the product’s life, some important changes meant it was not easy or practical to be fully backward compatible.

In this page, we’ll try to assist you to recover old ScanaStudio files (in case the latest ScanaStudio version is unable to open those files).

Files generated by ScanaStudio V3.0.17 or earlier

It is possible recover those files by following those steps:

Open your source file (ex: file.scana) with latest ScanaStudio 3.0.x release Save the file as file_30.scana As this point, file_30.scana is compatible with both 3.0.x and 3.1.x release of ScanaStudio.

Files generated by ScanaStudio V2.3

Ikalogic support is able recover those files, please contact [email protected] with the file (or files) that need to be recovered, and we’ll take care of making them compatible with the latest version of ScanaStudio.


CAN FD protocol

Adding FD (Flexible Data rate) support for CAN bus decoder

A couple of years ago, Bosch have released a new version of their famous CAN bus protocol, called CAN FD (FD stands for Flexible Data rate). Today, CAN-FD is quickly replacing all older CAN bus systems. To continue supporting our users in their daily debugging tasks, we have updated our CAN bus protocol analyzer to support latest CAN FD.

Working with CAN FD can be complicated (much more than standard CAN). A logic analyzer like the SP209i can be very useful to understand how your CAN system is working, or why is it not working.

What’s even more important that the logic analyzer device itself, is the software and the protocol analyzer.

But, What is CAN bus?

CAN bus a is communication protocol widely used in automobile and various industrial applications. It allows a master device (like a micro-controller) to communicate with multiple slave devices (like sensors) over a very long distance (maximum distance depends on bit rate used and bus design, but can usually be in the order of hundreds of meters). Unlike other protocol that only specify the physical layer (like RS232), the CAN bus specifies many layers of the network. As a matter of fact, CAN bus specifications covers data packetization and protection using various mechanisms like bit-stuffing and a CRC word at the end of the data frame.

More about CAN-FD

CAN FD protocol can be quite complicated, specially if you have to deal with the complexity of the hardware and firmware implementation. For instance, CAN-FD relies on various kinds of bit stuffing mechanisms (as compared to standard CAN where only one bit-stuffing mode is used).

Implementing a working CRC can be tedious. Now if a CRC is not complex enough for you, imagine having 3 different CRC polynomials depending on the number of bytes in a CAN frame, and two different bit-stuffing algorithms depending on the position of a bit in the CAN bus frame.

That’s where a good logic analyzer kicks in!

ScanaStudio to the rescue!

ScanaStudio logic analyzer software has a large range of protocol analyzers, including the CAN protocol. Protocol Analyzers are written to provide as much information and assistance to the hardware designer as possible, and CAN bus is no exception.

To get your CAN based system quickly debugged, start by connecting one of our Logic Analyzers to your CAN H and CAN L lines (or simply connect to the CAN line between the MCU and CAN transceiver).

Dedicated CAN receiver

Some logic analyzers have integrated CAN receivers and can be directly connected the CAN Bus differential lines pair. For instance, the SP209i (industrial) logic analyzer lets you directly connect to CAN bus lines (CAN H and CAN L). On the other hand, with the SP209 (standard) logic analyzer, you have to connect the logic analyzer to a CMOS compatible signal (a single-ended signal, operating on 1.8V to 5V level).

It’s good practice to capture some activity - any CAN bus activity - before going further to make sure your device is correctly configured and that’s you’re seeing CAN bus signals on the screen as expected.

CAN protocol analyzer

Then, add a CAN protocol decoder and configure it correctly, choosing the right channel and the right baud-rate. If you don’t know the baud rate, you can simply measure the bit time from some captured frames. Please note that in case of CAN-FD protocol, you also have to configure the (higher) Flexible bit rate

Adding CAN bus protocol analyzer

Expanding the “Display options” tab lets you configure how each part of the frame is displayed:

CAN bus display options

For example, in your specific application, it may make more sense to display CAN ID fields in binary format and data fields in decimal format instead of Hexadecimal format.

Exploiting the results

Once the decoder is added to the workspace, you’ll notice that “decoded items” appear on top of the CAN signals, as in the image below:

Correct CRC

You’ll also notice that the correct CRC is highlighted in green color. In case of a wrong CRC, it would be highlighted in red.

If you hover your mouse over any decoded item, you’ll notice some additional details, namely sampling points (as well as bit stuffing samples that are ignored bits):

CAN sampling point and bit stuffing

Now, I’ll let you open the HEX-View and Packet-View to discover new ways of digging through CAN frames!


Sensor+test 2019 in Nüremberg

Visitors asking me why they should switch from Saleae to Ikalogic...!

Just like last year, this year also we’re participating in Sensor + Test trade show in Nuremberg, Germany. It’s always a pleasure to meet new persons in that field, specially persons who are passionate about electronics and all that gravitates around it, but more importantly, we find it heart warming to meet to meet happy customers who have bought one of our logic analyzers sometime in the past 10 years.

Now, if you have ever been to this fair before (Sensor + test), you may wonder why we’re present at such a fair where all exhibitors are coming from a purely industrial field. Indeed, almost all exhibitors are selling HVAC (Heating, ventilation and Air Conditioning) sensors, as well as other industry-specific sensors like pressure sensor or flow meters. Well, as a matter of fact, there is electronics everywhere, and electronics need development, debugging, and eventually maintenance.

It’s funny though to see how many engineers still don’t know how much a logic analyzer can make your life easier when debugging a system involving communication protocols.

I also got asked several times, how does the SP209 series compares with the equivalent Saleae products. I tried to be as unbiased as possible. I start by saying how much I respect Saleae as a company that have disrupted the market in a very positive way. Let’s compare Ikalogic SP209 (standard version) VS Saleae Logic 8:

Hardware differences

Criteria Ikalogic SP209 Saleae Logic 8
Price tag 349€ 349€
Embedded memory 2Gb DDR3 N/A
External trigger IN/OUT Yes No
Trigger options Advanced (edge, pulse width, sequence, protocol) limited to edges or pulses
Configurable pre-trigger time Yes N/A
Analog inputs N/A Yes up to 10Msps (~1 MHz analog Bandwidth)

I am not comparing the list of supported decoders, as both Ikalogic and Saleae support a fairly good amount of standard protocols.

Still on the hardware part: you may notice Ikalogic’s SP209 do not have analog inputs, but, the trigger IN/OUT lets you synchronize your logic analyzer with the best and most powerful bench-top oscilloscope you’ve got your hands on. This, in my opinion, is much more important.

Software differences

Now to the software part. We share with Saleae the same philosophy about the importance of software. Both Ikaogic and Saleae offer a single software for the whole range of logic analyzers (which obviously makes it easier to maintain to software part). Ikalogic’s software solution is called ScanaStudio while Saleae’s is called Logic.

For the record, i’m comparing to logic v1.2.29

Here is a list of main aspects in which Ikalogic and Saleae software are different.

Alternative views

ScanaStudio offer “alternate views” which is a set of different ways to represent decoded signals. Decoded signals can either be display on top of the signals:

Can frame decoded*

… or as packets:

can frame packet

… or as HEX dump:

HEX dump

And the list is growing with every new software update. The idea here is to offer the user many different way to visualize the data, with each different view offering search and filter options.

Advanced decoder options

ScanaStudio offers quite advanced protocol analysis options compared to Logic. For instance, signals can be displayed in many formats (Hex / Ascii, binary) and, depending on the protocol, you may display the address field in HEX and the data field in ASCII (or whatever configuration makes more sense to make data more readable).

Also, ScanaStudio allows a protocol to either import data from a file, or export data from a file. For example, you may need build a CSV table for all decoded signals and format it in a way that allows easy graph drawing; this is totally possible and can be automated.

Signal overlay (signal editor)

This is one cool feature that can be very handy. Imagine you have a capture of some logic signals, and you wonder:

  • “What if there was a glitch?””
  • or “What if that signal was low instead of high, what the decoded value would be?”

Well, ScanaStudio can let you modify a signal with a few mouse clicks (this is called the signal overlay feature) as shown in the animation below:

signal overlay logic signal editor

Scripting

Okay, now we clearly have a different approach here. Saleae allows custom decoders to be added via an SDK (that implies having to actually compile C++ code). ScanaStudio, on the other hand, relies on (java) scripts (which implies that you don’t need to install any fancy compilers)

I can’t say which one is better, I leave this up to the reader’s judgement.

I’ll just add that ScanaStudio scripts are not only meant to be used to decode signals, but also add many add-ons to Scanastudio, like adding new trigger options or adding new signal builders (for devices that support signal generation).

Automation and APIs

Okay, to be fair, we are lagging on this part, as we currently offer no way of controlling the device and/or software from another application, but we are of course actively working on it!