# SPI transfer doesn't quite work on Netduino -> led driver

I have a TLC5916 led driver (manual here) that can power 8 LEDs as commanded through SPI by a microcontroller. The writing end of the SPI is a Fez Panda (.NET MicroFramework) uC. When I send data, I sometimes get correct results, but usually it's something that looks similar, but not quite like, what I sent.

It usually looks like the sent byte got left-shifted one bit, or got some of the bits flipped.

Trying to send the same byte again and again usually yields the same (wrong) output, but even there, I've seen slightly different outputs for the same input crop up every once in a while.

Note that the LED driver is powered at 5V (PC ATX source), and the Fez has 3.3V outputs.

Also, I've tried to read back the values from the LED controller (it has a SPI output pin for chaining multiple controllers). This time, the 5V values are read perfectly by the Fez uC - the values I read corresponded with what physical LEDs were lit. (The Fez documentation does say that 5V inputs are supported, so I guess this was expected)

I tried changing the sampling setting for SPI (rising/falling CLK edge), but same results for either setting.

Any suggestions for debugging?

I don't have an oscilloscope or digital probe :( .

• BTW, I highly recommend a Saleae Logic analyser. They don't cost much, and will save you hours of your life. – Rocketmagnet Apr 2 '12 at 22:11

Referring to the datasheet, page 8:

VIH High-level input voltage is 0.7*Vdd minimum. Which is 3.5v! This is higher than the 3.3v signals you are sending it. You're working just beyond the operating spec of the part.

You can use a voltage converter to boost those 3.3v signals to 5v.

OR

Reduce the 5v supply voltage of the TLC5916 a little. You could easily do this by adding a diode to its VDD supply pin. This will drop a little voltage. Might just bring it into spec. Make sure that the diode's forward voltage drop is about 0.7v.

• Wow. I missed that in the manual -and I looked for it!- ...or maybe I didn't understand it. Thanks for pointing it out! I'd rather not do the diode fix, I expect pretty large currents on that route - driving 512 leds in bursts, last time I calculated, the current was in the Amps range... I'll see how I can bring the 3V3 signals up. – Cristi Diaconescu Apr 1 '12 at 21:56
• Look for a voltage translator, TI do lots of them, even some clever auto direction sensing ones. – Rocketmagnet Apr 1 '12 at 22:00

This might be the issue, but many times these shift registers work outside their stated minimums, so you might also want to try all four permutations of the idle state and sampling clock edge. I put a saleae on a shift register I was using once (mbi5026), and found that while it would work with different settings, there was a best combination that made it work correctly every time. Prior to finding the right combination, I saw discrepancies just like those you mention.

You could also vary the clock speed and see what happens.

        Device1 = new SPI.Configuration(
Pins.GPIO_PIN_17, // SS-pin
true,             // SS-pin active state
0,                 // The setup time for the SS port
0,                 // The hold time for the SS port
TRY BOTH - true,              // The idle state of the clock
TRY BOTH - true,             // The sampling clock edge
100,              // The SPI clock rate in KHz
SPI_Devices.SPI1   // The used SPI bus (refers to a MOSI MISO and SCLK pinset)
);

• Thanks! Maybe this will motivate me to dig up that stalled project and give it another try :) – Cristi Diaconescu Jan 27 '14 at 11:45