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:
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?
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:
Rich (BB code):
writeLED(1);
CS_LED = 1;
CS_EEPROM = 0;
//while(1);
SPI2BUF = 0x0002;
//while(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?