top of page

MicroZed Chronicles: Custom Board Design? What if something doesn’t work?

A couple of weeks ago I was working to bring up the sensors connected to the I2C and SPI interfaces on the custom SensorsThink Smart Sensor IoT Board that Dan Binnun and I have designed. Connected to the I2C networks are several sensors including accelerometers, magnetic sensors, linear accelerometers and temperature.

When I ran the I2CDetect commands on the four I2C buses, we saw the expected responses on I2C-0, I2C-2 and I2C-3. However, I2C-1 did not contain the expected response which shows the address of any sensors connected to the network.

I was expecting to see the temperature sensor at address 0x70 on 12C-1 bus but there was no response.

So, what do we do in a situation where we are bringing up a custom board and something does not respond as expected or as we would like? Of course, it’s important not to panic. Often the cause is something relatively minor, however, there are several potential causes which must be considered so the issue can be corrected.

When this situation occurred, the first thing I did was check the device tree and PetaLinux configuration to ensure the AXI I2C controllers are correctly configured. When I checked, the declaration for I2C-1 looked the same as it did for the remaining two.

Satisfied that the device tree and PetaLinux configurations contain no errors, my next step was to double check the pin out in Vivado to ensure I had allocated the SAD and SCL pins to the correct pins on the FPGA. Again, double checking the Vivado constraints against the released schematics showed that the SDA and SCL pins where on the correct balls.

At this point, I was confident the device tree, PetaLinux, and Vivado XDC constraints where correct.

Sadly, not finding any issues in the configuration of the FPGA and operating system indicates that the issue may reside in the hardware.

At this point, it is time to break out the oscilloscope and check the status of the SDA and SCL lines on I2C-1 when the bus is in action. Ideally if the bus is working correctly, we will see clock pulses on SCL and data pulses on SDA.

I2C uses an open drain technology, where the master and slaves only drive the bus to a logic low. To transmit a logic one, the open drain IO relies upon pull up transistors on the SDA/SCL lines. There are several hardware issues which can impact the line. This includes anything from the wrong value pull up being fitted, to the pull up resistors not being populated at all.

Using an oscilloscope to monitor the lines initially when no transactions are present showed the following.

The SCL line looks correct with the idle line sitting at 1v8.

However, the SDA line looked unexpected with the line sitting at about 0.6 volts. This indicates a potential hardware issue and the root cause of which needs to be identified.

The first point of the hardware examination is to verify the correct placement of the pull up resistors. With these confirmed, the next step is to examine the temperature sensor itself.

Here is where the fun begins because the temperature sensor is tiny and surface mounted

Looking at the results of the oscilloscope, we can see there is something pulling down the SCL line. Examining the footprint of the temperature sensor on the board shows that if the manufacturer had fitted the device with the wrong orientation, the results would be the exact same as what we are seeing.

To correct this issue, the component must be removed, rotated and re-attached to the board. We classify this issue not as a design issue but a manufacturing issue because the component was placed incorrectly.

In summary, these are the generic steps that can be taken when you are bringing up your custom board and encounter an issue.

1. Verify the operating system configuration – especially device trees and packages in the PetaLinux configuration.

2. Verify the configuration of the IO pins in Vivado.

3. Probe the line when active and inactive to observe any unexpected waveforms.

4. Examine the layout and assembly drawing to determine any placement issues.

Now that we know what’s necessary to get the temperature sensor on the SensorsThink Smart Sensor IoT Board up and running, I better break out the soldering iron.



bottom of page