Introduction: Open Your Eyes! Logical Analyzer

By Visit my Site!
About: Do you like technology? Follow my channel on Youtube and my Blog. In them I put videos every week of microcontrollers, arduinos, networks, among other subjects.

The logic analyzer facilitates your visualization of the pulse train, which are the bits traveling in a line of communication. Thus, it opens your eyes to identify a possible problem. Why is this important? It’s a very efficient development and fault detection tool that can save you time. In this video today, we’ll evaluate the importance of the logical analyzer, observe some protocols of common practices while using this device, and exemplify a detection failure without the aid of a logic analyzer.

In this video, I used a relatively inexpensive (around $35) and efficient model, with a graphical interface and free software.

Step 1: Assembly

Step 2: Features Used - Server

• Jumpers for connections

• 2 Arduinos (we used 2 Mega Arduinos 2560)

• Logical Analyzer (we use Saleae)

• USB connection cables for Arduino and analyzer.

• Oscilloscope (optional)

• Protoboard

Step 3: Circuit Used

Here we have the schematic, which shows the monitoring of three pins: TX0, SDA, and SCL. We have two Arduinos: a master and a slave.

Step 4: Source Code: Master

In the Setup, we will include the library for i2c communication. We entered the network as Master and initialized serial 0. In the Loop, we requested slave data bytes for communication with our Arduino number 8, as we defined in the example. We print in the serial, which will be evaluated with the logic analyzer, the bytes received.

#include <Wire.h>  //inclui a biblioteca para comunicação I2C
 
void setup() {
  Wire.begin(); // Entra na rede como Mestre (endereço é opcional para o mestre)
  Serial.begin(115200); // inicia a serial 0
}
 
void loop() {
  Wire.requestFrom(8, 6);// requisita 6 bytes de dados do escravo de endereço 8
 
  while (Wire.available()) { // enquanto houver bytes para receber . . .
    char c = Wire.read(); // recebe cada byte e armazena como caracter
    Serial.print(c); // envia o caracter pela serial (na verdade vai para o buffer)
  }
 
  delay(500); //aguarda meio segundo
}

Step 5: Source Code: Slave

In this slave code, I again include the library for i2c communication. I enter the network as a slave with the address 8. We register the request event and associate it with the "request" function. You do not need to do anything on the loop, just give a 0.1 second delay.

Finally, we have the request function that will be executed when the request event by the Master occurs, which was registered in Setup. We reply, finally, with a message of 6 bytes.

#include  <Wire.h>//inclui a biblioteca para comunicação I2C
 
void setup() {
  Wire.begin(8); // entra na rede como escravo com endereço 8
  Wire.onRequest(requestEvent); // registra o evento de requisiçao
                                // e associa à função requestEvent
}
 
void loop() {
  delay(100); //não faz nada no loop, apenas aguarda 0,1 segundo
}
 
//função que será executada quando ocorrer o evento de requisição pelo mestre
//foi registrada como evento no setup
void requestEvent() {
  Wire.write("teste "); // responde com uma mensagem de 6 bytes
}

Step 6: Analyzer: Hardware

Sample rate up to: 24 MHz

Logic: 5 V to 5.25 V

Low-level threshold 0.8 V

High-level threshold 2.0 V

Input impedance of about 1 Mohm or more

Step 7: Saleae Software Installation

The program that receives the data captured by the logic analyzer and decodes the bits can be downloaded at the following link: https://www.saleae.com/downloads/

Step 8: Configuring the Environment for Our Tests

I show the interface here, which I particularly liked because it was clean.

Step 9: Configuring the Environment for Our Tests

Here are some configuration options:

• By clicking on the channel name, we can change it.

• We can determine whether one of the channels will serve as a trigger for capture and the form of detection.

• By clicking and holding the channel number, you can change your position in the list.

• By clicking on the gear, we can configure the channel visualization, expanding ...

• ... or hiding the channel. We’ll hide all the channels we won’t use.

Step 10: Configuring the Environment for Our Tests

Clicking on the arrows of the "Start" button, there are the options of Sampling Rate and duration of the recording.

For some reason, if the software detects that the rate cannot be maintained, a message will be displayed and automatically the rate will be reduced until a functional value is reached.

Step 11: Configuring the Environment for Our Tests

We’ll also include the protocol analyzers. First it’s the I2C, following the definitions of the WIRE library, and associating the channels correctly. Finally, we’ll introduce the analyzer to asynchronous serial. We need to be careful to correctly configure the parameters according to the assembly.

Step 12: Configuring the Environment for Our Tests

In the "Decoded Protocols" tab, we should check which protocol analyzers are enabled. There, the data will appear. In the "Annotations" tab, we can add some of the results for better visualization. Just click on the "add measurement" icon.

Step 13: Capture: Overview

In the capture screen, the program displays the data pulse train of the SDA, SCL, and TX0.

Step 14: Capture: Result of Protocol Analysis

Here, we see the result of the capture. In the "Decoded Protocols" tab, we have:

• The server request for the slave with id 8.

• The slave response, six characters: "t", "e", "s", "t", "e" and a space.

• Each is followed by an ACK bit (Acknowledge) indicating correct byte reception, except for the NACK (Not Acknowledge) space character.

• Next, we see the decoding result of the TX0 serial, indicating the characters received and sent to the Arduino IDE serial terminal.

Step 15: Capture: Channel 0 and Data (SDA)

In this image, we have the pulse train of the SDA line. Note that each transmitted byte can be viewed.

Step 16: Capture: Channel 1 and Clock (SCL)

Now, we have here the pulse train of the SCL line. You can check more details simply by positioning the mouse over the signal, as you see in the image. We can see that the clock frequency was at 100 kHz.

Step 17: Capture: Channel 2 and Serial (TX0)

As for the pulse train of the TX0 line, we can see the Start bit and the framing points of each bit. We have a byte representing the character "e."

Step 18: Configuring the Environment for Our Tests

Here we have several options for reading the data.

Step 19: Capture: Oscilloscope and Analyzer

Look here at the screen I captured from my oscilloscope. The logic analyzer signal represents only the high and low detections, but it does not represent the signal quality. This can best be observed on an oscilloscope.

Step 20: Capture: Observing a Failure (example of Serial Failure)

Now, I’ll show an example of a serial failure, which actually happened to me. I was with a GPRS modem, the kind used on a cell phone, the SIM card, trying to connect to the ESP32. But it just didn’t connect. I then checked the power supply, the wiring, and changed the board. I did everything, but nothing fixed it. I decided to put in a logical analysis: I discovered that the ESP signal on UART 115200 began to mismatch. That is, the ESP32 was playing what should be 115,200 at a different speed than this.

This error, which was identified by the parser, was displayed with an X in red. In my understanding, the program says that the point that has such a bit is half-displaced in time. As this shift increases, there may come a time when everything is mismatched, so that information does not reach the other side. It usually arrives, but the SIM800 is sensitive and if it isn’t exact, the information does not reach the other end.

I do not know if this is something that happens often or not, but it happened to me, and so I decided to address this subject here. So what did I do? I slowed down. If you put 9,600, 19,200, up to 38,400, it works, which does not occur with the 115,200.

Step 21: Download the Files

PDF

INO