I have a PIC connected to a STP16CP05 LED driver and a 25LC256 EEPROM, both through SPI.

The LED driver is connected to two 7-segment digits. The code to write data to the LED driver works great. However, I noticed that the driver essentially ignores its CS pin. My functions that write to the EEPROM make the LED driver update its display!

I thought of course I might be accidentally enabling the LED driver, but this is not the case. Here's the debugging I have done:

writeLED(1);
CS_LED = 1;
CS_EEPROM = 0;
//while(1);
SPI2BUF = 0x0002;
//while(1);

If I uncomment the first infinite while loop, the only code that executes is the code to write the number 1 to the 7-segment display, and the code that deselects the chip select on the LED driver and selects the chip select on the EEPROM. I have verified with the multimeter these readings, and the display updates accordingly with the number 1.

If I only uncomment the second infinite while loop, the only change from the previous test is that I put some data in the transmit buffer, which should go to the EEPROM. The LED driver should not be affected because the chip select is high. However, the LED driver writes that value to the 7-segment display, and messes up the number 1 it previously wrote - even though chip select is high! (Again, verified with multimeter that its chip select is high).



The VDD of the LED driver is 3.3V, and when its chip select is high, the voltage of the chip select pin 3.04v, which is within 0.7*VDD which the datasheet specifies.

Is this a problem with the SPI LED driver? Considering its chip select is always high, it should not be affected by any data going through the SPI lines - but it is. Could their chip really be faulty? What could I be doing wrong such that the SPI driver is "active" even though chip select is high?

 

Active high chip selects are not common. They are normally active low.

From a state where ALL chip selects are inactive, here is what you should do:
1. Make CS "active"
2. Write SPI Data
3. Wait for SPI Data to be completely shifted out of the SPI shift register
4. Make CS "inactive"

After completing these four steps the system is returned to a state where ALL chip selects are inactive.

 

Active high chip selects are not common. They are normally active low.

Both these devices are active low - the problem I am experiencing is that the LED driver appears to be active even though the chip select is high, which should disable it.

 

It is hard to help you when so much of the relevant detail is missing from view. What does the writeLED(1) function do? What processor are you using? Where are the pin definitions for CS_LED & CS_EEPROM? what data are these two devices sending back. Are the outpouts in a high impedance state when deselected? Where is the schematic?

There are any number of things that could be going wrong, and I guess we have to eliminate them one at a time.

 

It is hard to help you when so much of the relevant detail is missing from view. What does the writeLED(1) function do? What processor are you using? Where are the pin definitions for CS_LED & CS_EEPROM? what data are these two devices sending back. Are the outpouts in a high impedance state when deselected? Where is the schematic?

There are any number of things that could be going wrong, and I guess we have to eliminate them one at a time.

I'll try and get some more code posted, its kind of all over the place at the moment

 

It looks like the latch input is what you want, an active-high input, but you are using active-low logic as your select. This makes me think you are trying to use #OE to select the device. Are you?

Look at table 9 and figure 8 in the datasheet you linked...

 

Gah, that was it!!!! When I looked at it before, I looked at the timing diagram and just assumed it was an active low device. Turns out it is an active high device!

I just flipped the highs n lows in my code and it works great.

Before, even though I had it backwards, it would still work because it was the only SPI device.

Thank you both of you

 

Glad to hear you have it working!

Checking the truth table is one of my first steps when using this sort of device...