STP16DP05 - Correlation Between OE (Output Enable) and Data Transfer for LED Matrix Row Scanning

[shreyav]

I am currently working on a row-scanning LED matrix application using STP16DP05 and a NXP imxrt1064 MCU. I’m encountering some synchronization issues and would appreciate some clarity on the following:

1. OE (Output Enable) and Data Transfer Correlation: Is there a strict correlation between Data Transfer (Clock/SDA) and the OE pin? Specifically, can I keep OE enabled (pulled Low) while shifting in new data and pulsing the Latch (LE) pin? I am trying to determine if OE must be disabled (High) during the entire transfer-to-latch sequence because if i keep OE grounded all the time, I'm seeing unexpected behavior on LED display.

2. Brightness Control Alternatives to PWM: Are there recommended methods for implementing brightness control other than standard PWM? I am looking for techniques that will be implementable with SPI as that is the protocol im using for data transfer.

3. PWM/Bit-Shifting Issue in Row Scanning: Currently, when I implement PWM for brightness, I am seeing unexpected "bit-shifted" outputs. I am using a row-scanning method (switching rows after a full data frame is latched). It appears the data is "bleeding" or shifting across pixels incorrectly during the PWM cycle.

Has anyone faced issues where the PWM clock interferes with the Latch/Shift timing in a scanned environment? Any advice on the ideal way to control brightness.

[shreyav]

Please reply to my query asap, im facing a lot of issues with this driver

[Peter BENSCH · Accepted solution]

Welcome @shreyav, to the community!

You did not include a program snippet, so I will respond in general:

1. Relation between OE, Data (CLK/SDI) and Latch (LE)
   • electrically you can keep OE low all the time, but for a scanned + PWM system this causes visible glitches
   • Recommended sequence per update:
     • OE = High (outputs off / blank).
     • Shift all data via SPI (CLK + SDI).
     • Pulse LE once after the last clock edge to latch the full word.
     • Small delay (ns...µs).
     • OE = Low (outputs on).
       
       Keeping OE permanently low means intermediate shift-register states and bad latch timing will become visible = “ghosting” and apparent bit shifts.
       
       
2. Brightness Control
   • The STP16DP05 is a constant‑current sink, so in practice brightness always comes from controlling the on‑time (= PWM on OE):
     • Global brightness: reduce the overall on‑time per frame
     • Subframe / bit‑plane PWM: Split a frame into time slices (e.g. weighted 1,2,4,8…). For each slice, send a different bit‑plane via SPI, latch, then enable OE for the corresponding duration, which gives multiple brightness steps without per‑pixel timers, just different data + OE timing
       
       
3. Bit-Shift / Bleeding Issues with PWM + Row Scanning
   • Usually mean timing conflicts between:
     • OE toggling while SPI is shifting
     • LE pulsing too close to a CLK edge
     • Row selection changing while outputs are still enabled
       
       
   • Try this pattern per row (and per PWM subframe if used):
     • OE = High (blank)
     • Select the row
     • Shift full row data via SPI
     • Pulse LE once (away from CLK edges)
     • Short delay
     • OE = Low for the intended on‑time
     • Next row / next subframe
       
       
4. Maybe helpful:
   • Make sure you shift integer multiples of 16bits
   • Avoid hardware PWM on OE not synchronized to SPI/latch
   • Maybe reduce SPI clock to rule out signal integrity / timing margin issues
     
     

Hope that helps?

Regards
/Peter