Electronic – arduino – SPI Troubleshooting, Teensy, Arduino, and tri-state

arduinodriversdspitri-state

I'm trying to get my SPI bus devices up and running on a custom circuit board that I've soldered together. Unfortunately, I neglected to add probe testing spots on this particular circuit board, and don't think I can directly test the SPI bus signals at the ICs. One is a 20 pin LED Current Sinking Driver in a SSOP package and the other is a microSD card holder.

I can't seem to get either device to work.

My MCU is a Teensy 3.1. (Arduino-compatible) In terms of firmware, I'm using Arduino v1.06 (highest version supported by Teensyduino), and Teensyduino V1.20. I'm using the SPI library/object for comms with the LED driver, and the SdFat library for comms with the sd card.

Here is the schematic of how my LED driver and SD card are hooked up:

LED Driver Shchematic

SD Card Schematic

According to the TLC59025 Datasheet, the timing diagram for communicating with the LED driver is as so:

SPI Timing diagram for TLC59025

My method of testing thus far, other than software (i.e. trying to open a file on the sd card), has been as follows:

  • Made sure that the 3.3 V LDO serving the SD card was outputting correct voltage
  • Attempted to begin serial comms with SD card using SdFat library (this was a no-go)
  • Measured voltage at various LED Driver out pins, before and after sending two 8-bit words to the LED Driver's MOSI pin and pulsing LE high

If the particular LED output pin is latched and sinking current, then the voltage I measure at that pin should be near 0 V, correct?

My Master SPI clock speed is around 2 MHz. I know that the TLC59025 says it's operating point is 30 MHz. I thought that as long as the Master is using a SCK that is lower than the slave's clock, the comms would work. Am I wrong?

I thought that perhaps tri-state behaviour was to blame for my woes, however it looks like the TLC59025 LED Driver is designed to always be accepting data into it's shift register, even when it is not the intended slave being communicated with. It looks to me as though it is designed to simply latch the last 16 bits of data sent over the SPI MOSI bus whenever the LE pin is pulsed high.

I'm stumped as to how to proceed with troubleshooting. I know that the problem shouldn't be due to the MISO bus, since I only have one device (the SD card) hooked up on that bus.
Could it be the MOSI bus? Is it possible that there is too much capacitance on the MOSI bus when I'm trying to communicate, thus degrading the data signal? If I add a tri-state buffer to the MOSI/CS signals on the SD card, and a pullup resistor on the chip select signal of the sd card, would that help maintain signal integrity on the MOSI bus (ie cut down capacitance of MOSI bus to the point that at least the LED driver should work?).

Best Answer

SD Card access is a fair bit more complicated because of the need to consider the FAT file system etc. So if I were you I would concentrate on getting the LED driver working first; at least then you know your SPI bus is working.

To answer a few of your questions:

  1. The voltage at the output of any LED output pin will be the voltage that is required to achieve the programmed constant current. It should not be 0V unless the outputs are set for maximum current. And it should not be the supply voltage unless the LED is supposed to be off.
  2. The fact that the LED driver has an internal 30Mhz clock should not be of concern to you. Your device is the master, it controls the clock, and the slave should clock in the data based on the clock your master provides to it. The 30Mhz info is just useful in terms of appreciating the maximum speed you can push data through the device.

A few things to check:

You mention pulsing LE high, but you don't mention holding OE low to enable the LED outputs?

You need to make sure you've configured the master clock and data pins properly. I am not familiar with Arduino stuff so I can't help you with the specifics here, but there are various modes of SPI operation and you'll need to set up your device to match. You need to make sure you have the correct mode set up to output the data on the rising edge of the clock, with data sampled in the middle (for the LED driver - maybe it's different for the SD!).

Where is the chip-select pin on this device? Surely it has one? Couldn't see it on the supplied diagram. If there is no chip-select, how will you switch between data provided to the SD card and data provided to the LED driver? You'll need two SPI peripherals? Unless perhaps the LED driver is happy to just sit there receiving data, even if it isn't the intended recipient, and it's up to you to control the LE and OE pins when it is the intended recipient. It's worth just looking into this to clarify everything.

I'm not sure what is supposed to come out of the LED driver SDO pin? Are you using it?

How is SDI supposed to relate to LED outputs? I notice in the timing diagram SDI is high for bits 0, 2, 5, 10, 11, 12, and 15. But outputs 0, 3 and 15 are shown to respond with an 'ON' condition. Maybe this is explained elsewhere in the datasheet, because it doesn't seem to make any obvious sense from the timing diagram...

Good luck!