Lots of people put guides online with simple steps to explain how to connect to and get data from ICs using a development board. Usually, the process in pretty simple. But for more complicated ICs, you’re not always that lucky. The first connection often takes some debugging. This is not a ‘simple guide to connect devices’ but rather a more careful look through the datasheets and debugging that is not often documented online. Engineering often has times when you’re looking for a needle in a haystack – or that 1 line in the 100 page datasheet that explains your problem. This post aims to document some debugging, which is much easier when you know that datasheets are not scary and measuring stuff is fun!
As part of the Battery Management System for the Midnight Sun Solar Car team at the University of Waterloo, I have been working on getting the external communication interface of the LTC6811 Battery Stack Monitor IC to interface with a large number of thermistors. We need to measure 2 thermistors for every group of 25 parallel cells on our battery pack as well as 1 ambient temperature sensor for every 2 series groups. The many ambient sensors are placed throughout the pack in an attempt to quickly identify spikes in ambient temperature that could be indicative of a cell venting. This adds up to a total of 30 thermistors per LTC6811 chip, plus a thermistor on the PCB for the balancing resistors.
An image of the battery modules is shown below:
To measure all of these thermistors, the external communication interface on the LTC6811 was used to communicate with the ADG731 32-channel analog multiplexer. The output of the multiplexer connects to one of the GPIO pins on the LTC6811 to be read as an Auxiliary analog input to the chip.
Testing and debugging this interface turned out to be a little trickier than planned. As usual, the answer was in the datasheets.
Let’s first get a bit of background on the ICs.
Datasheet for LTC6811-1: https://www.analog.com/media/en/technical-documentation/data-sheets/LTC6811-1-6811-2.pdf
Many images in this document are from the datasheet.
The LTC6811 is a 12 channel battery stack monitor by Analog Devices. It features 12 independant cell measurement inputs, and dedicated cell balancing pins. Communication to the chip happens over SPI, or by using the LTC6820 ICs an isolated isoSPI interface can be implemented. Also present an external communication interface that can be used to send either SPI or I2C commands to external devices. This is the external interface that is used to communicate with the ADG731.
Datasheet for ADG731: https://www.analog.com/media/en/technical-documentation/data-sheets/ADG725_731.pdf
Many images in this document are from the datasheet.
This device is a 32:1 channel analog multiplexer, control with a CLOCK, SYNC, and DATA signals. It mentions that the interface is compatible with SPI (but there is a catch here – read on). The mux has an internal shift register which shifts data in from the DATA input on the CLOCK signals.
When connecting it all up and reading the Auxiliary analog inputs on the LTC6811, garbage data was observed, and probing around with a multimeter proved that the pin was indeed floating. So it seems the ADG731 output was never enabled.
All the hardware connections were double-checked with a multimeter to ensure proper connections and no shorts. Still no output, so attention was turned to the firmware. Looking through the driver that the team (UW Midnight Sun Solar Car Team) had put together for it, a missing Packet Error Code CRC calculation was found in the WRCOMM command, and the COMM register byte order mistake were both fixed. A logic analyzer was used to check the communication interface to ensure that the LTC6811 was actually outputting data at this point, and it all seemed fine (or so I thought). Note that the SPI decoder in this image is set to SPI Mode 2, which is what the ADG731 would be reading.
Time to do a deep dive into the datasheets
Two pieces of info were found that Identified the problem:
1: The LTC6811’s external communication interface operates in SPI Mode 3. This means that the clock idles high, and data is shifted out on the falling edge and sampled on the rising edge of the clock (https://www.analog.com/en/analog-dialogue/articles/introduction-to-spi-interface.html).
2: The ADG731 shifts data into the input shift register MSB first, on the falling edge of the clock.
From this information, the LTC6811 external interface is not directly compatible with the ADG731 since the data shift phase is opposite. The LTC6811 will be shifting out new data as the ADG731 is reading the bus. Looking at the logic analyzer output above, it can be confirmed that different data is sent from the LTC6811 than is received with the ADG731.
Fixing the Communication
Looking at the waveform on the logic analyzer and double checking on the oscilloscope, I figured the clock signal of the LTC6811 SPI Mode 3 interface could be inverted to achieve a waveform that would successfully clock data in to the ADG731 Input Shift register in the correct order. Essentially, this would turn the interface into SPI Mode 1 for the ADG731.
A simple circuit using a transistor and some pull-up resistors could be used to achieve this clock inversion. I had some 2N3904s on hand, but no small FETs so I went with that. The LTC6811’s GPIOs are open-drain. Just to be sure, as mistakes are often made in small analog circuits, I fired up LTSpice and made the schematic to make sure I wasn’t out of my mind. The circuit simulated as expected and we got an inverted signal on the output.
This trace of the CLK line shows the rise times on the inverted clock are a bit long, but a less ancient transistor and an SMD footprint should make them look a little nicer due to the reduced parasitics. The long GND lead on the oscilloscope probe is also likely playing in to some of the error here. We do see the important parts though – we have 8 clock cycles to shift the data in, and they rise above the 2.4V logic high threshold of the ADG731.
Connecting up the logic analyzer once more, the output was now correct. Here, switch 5 of the ADG731 is activated. The SPI decoder in this image is in SPI Mode 1, which the ADG731 would read correctly.
Here’s an image of the test setup and probing – yes, its messy and eventually I’ll get some better tools and equipment to make this all neater – but for now, this is all there is:
Some useful data was finally received through the microcontroller. I had connected some thermistors and fixed resistors to the mux inputs and measured the correct voltage values.
The datasheet is always right. It often amazes me how much information is stuffed in there, and that they manage to get all the relevant information across without mentioning silicon structure of the chips or anything like that – block diagrams are all they need.
The external communication interface and GPIO Auxiliary input pins of the LTC6811 was used to successfully read 32 thermistors through the ADG731 analog multiplexer.