cancel
Showing results for 
Search instead for 
Did you mean: 

STP16CPC26 won't do anything

DSudo.2
Associate III

My apologies if this is the wrong ST forum... it seemed like the closest one to the part I'm using.
I have a new STM32F072 board design that has a STP16CPC26 LED driver connected to one of SPI busses. I just could not get the chip to do anything using the SPI bus, so I switched to a dirt-simple bit-banged (temporary, throw-away) driver so that I could easily change any aspect of the timing to make the chip work. Same problem... no matter what I do none of the outputs ever turn on and the SDO output stays low all the time. I've used a DMM to ensure it's properly connected to power and ground and that the supply voltage is okay (it's at 3.3V). I've had 3 other embedded developers look at the scope traces of the SDI, CLK, LE and OE- signals and they all agree that the timing and sequencing matches what the datasheet says you have to do to make the part work, but... it acts like it's dead. I've tried 5 different boards, and none of the outputs on any of them ever change state. I've also verified that the rise time of the SCLK signal is okay. Here's the bit-banged driver code. Can anyone suggest me to anything to do differently to make the part work? Does anyone know if there are any counterfeit STP16CPC26 chips in the supply chain? Any help would be appreciated.

 

void delay() {
  systick timer = TimerGet();
  while (TimerElapsed(timer) < 1)
    ;
}

void LEDs() {
  static uint32_t value = 0x55555555;
  delay();
  OUT_EN = 1;
  delay();
  LATCH_EN = 0;
  delay();
  for(int i = 0; i < 16; i++) {
    delay();
    SPI_LED_MOSI = (value & BIT(i)) ? 1 : 0;
    delay();
    SPI_LED_SCLK = 1;
    delay();
    SPI_LED_SCLK = 0;
  }
  LATCH_EN = 1;
  delay();
  LATCH_EN = 0;
  delay();
  OUT_EN = 0;
  delay();
  value ^= 0xFFFFFFFF;
}

 

 

1 ACCEPTED SOLUTION

Accepted Solutions

Can You show your schematic. If the MCU is powerd by 3.3V and the STP16CPC26 by 5V you are violating the min. Vin voltage (0.8*5V = 4V against 3.3V from the MCU)

MHoll2_0-1750515444769.png

 

View solution in original post

9 REPLIES 9
DSudo.2
Associate III

Additional info... we have a1K ohm resistor from the R-EXT pin to ground, which should give about 20 mA on each output. Also, I mis-spoke when I said the supply voltage was 3.3V. It's not, it's 5V. We have a little test board with banks of blue LEDs with anodes connected to 5V through 175 ohm resistors, and cathodes connected to the LED driver outputs.

The biggest mystery to me though is why there's no activity on the SDO output no matter what we shift in on the SDI pin. Surely it has to be coder error, but I just can't see anything wrong with the signals applied to the LED driver.

#ifndef BIT
#define BIT(n) (1U<<(n))
#endif

Also... the LEDs function is only called twice per second, which should be plenty of time to see the LEDs turning on and off. I can change the initial value of the "value" variable to 0 or 0xFFFFFFFF and comment out line 28 so it never changes, but that has no effect on my symptoms.

I saw that ST makes eval boards with this part, and that they include firmware to make them work, so I downloaded the firmware and copied the relevant parts to a freshly created STM32Cube project. Other than changing the I/O pin assignments, I left all the SPI bus parts alone, built the code and ran it on my board. The SPI bus peripheral worked as expected and the waverforms (other than being faster) matched what my bit-banged driver did. Unfortunately, still no LEDs turn on. I'm ordering one of these boards overnight to (1) see if they work, and if so to (2) compare signals between boards. If there's no real difference between the signals, I'll try loading my code (with different I/O pin assignments) into the eval board. If my code works on the eval board I'm not sure what to do next. The conspiracy theorist part of me got really suspicious when I saw that there's a company with a Chinese sounding name (New Yang Tech at nyang-tech.com) offering to sell these chips for a penny each. I have not yet been able to locate anything that describes the package markings so that I can see if these chips at least look legitimate. Can anyone point me to a source that explains the package markings and/or tell me if these package markings look like these chips are counterfeit or not?STP16CPC26 TOP.png

DSudo.2
Associate III

I see that Peter BENSCH (ST Employee) in November 2023 answered another poster's question about component markings by telling them that this info is internal and not published.

https://community.st.com/t5/interface-and-connectivity-ics/part-marking-decoder/td-p/266605

Can anyone at ST answer my question about the component markings in the above pic?

Thanks.

DSudo.2
Associate III

Ok... here's a simpler question... if the chip is properly powered and I hold the SDI input high while generating clocks on the CLK pin, should the SDO pin go high? Mine doesn't. I even bought a TSSOP to DIP breakout board, very carefully soldered a new chip onto it, and basically dead-bugged power, ground and all the control signals from the breakout board to my board (after first removing the chip from my board, and not connecting SDO or any output pins to the breakout board), and still... nothing ever comes out on the SDO pin. The SDO pin has a push-pull driver so no pullup is required. Is there anything "special" that needs to be done to get the SDO output pin to work?

DSudo.2
Associate III

ST online support confirmed that the part markings appear consistent with their expectations. Still no clue why SDO is stuck low even when that pin is a no-connect. I knew it didn't need a pull-up, but I tried a 4.7K one anyway and as expected it had no effect. I'm really stumped, which is embarrassing for such a simple chip. Sigh.

Can You show your schematic. If the MCU is powerd by 3.3V and the STP16CPC26 by 5V you are violating the min. Vin voltage (0.8*5V = 4V against 3.3V from the MCU)

MHoll2_0-1750515444769.png

 

DSudo.2
Associate III

Oh my goodness... what a rookie mistake! Thanks so much for solving that problem... it was driving me crazy. Sounds like our design review process needs one more thing added to the checklist.