Other Parts Discussed in Thread: DLPA2005, DLP2010LC
We have a set of custom boards that include the DLPC3470, DLPA2005, and the DLP2010LC. We control the DLPC3470 from an external MCU via the I2C interface. We are using v8.1.0 of the firmware downloaded from the DLP Pico FW Selector (I have tried the latest, v9.1.0, and it did not solve the issues described here) and have loaded our own custom pattern table into it via the DLP EVM GUI (v3.2.0.6). For our application we place the DLPC3470 in two operating modes: splash screen mode and internal pattern streaming mode. I have observed inconsistent behavior in both of these modes, which I will describe below.
Splash Screen Mode
In our application, we need to periodically adjust the LED drive strength used for the splash screen. This adjustment takes place over a 1s internal. To make the adjustment, we write the RGB LED Enable (0x52) and RB LED Current (0x54) registers as follows:0x52 = 0x1
0x54 = 0x94 0x01 0x01 0x00 0x01 0x00
In the above example we are using only the blue LED at a drive strength of 1000mA. The behavior I have observed is that, inevitably, one of these transactions will trigger a reset on the DLPC3470, at which point I observe HOST_IRQ pull high and then back low after a few hundred milliseconds. At this point the projection becomes corrupted, usually displaying a full blue rectangle rather than the configured splash screen. This behavior occurs regardless of the rate at which we make the updates (I have tried many different intervals from 1Hz to 20Hz), the LED currents we set, or the LEDs we chose to enable/disable.
Internal Pattern Streaming Mode
Internal pattern streaming mode is our application's primary operating mode. When we enter this operating mode we place the DLPC3470 in internal pattern streaming mode, push a pattern sequence table to the controller over the I2C interface, and trigger the controller using the external input trigger. An example configuration sequence over I2C is shown below:0x52 = 0x07
0x54 = 0xFA 0x01 0xFA 0x01 0xFA 0x01
0x9D = 0x01 0x00 0x98 0x08 0x00 0x00
0x9D = 0x01 0x00 0x82 0x08 0x00 0x00
0x9D = 0x01 0x00 0x6D 0x08 0x00 0x00
0x9D = 0x01 0x00 0x58 0x08 0x00 0x00
0x9D = 0x01 0x00 0x43 0x08 0x00 0x00
0x9D = 0x01 0x00 0x2E 0x08 0x00 0x00
0x9D = 0x01 0x00 0x1A 0x08 0x00 0x00
0x9D = 0x01 0x00 0x06 0x08 0x00 0x00
0x9D = 0x01 0x00 0xF2 0x07 0x00 0x00
0x9D = 0x01 0x00 0xDE 0x07 0x00 0x00
0x9D = 0x01 0x00 0xCA 0x07 0x00 0x00
0x9D = 0x01 0x00 0x66 0x07 0x00 0x00
0x98 = 0x01 0x02 0x08 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x66 0x07 0x00 0x00 0xB3 0x00 0x00 0x00 0x20 0x00 0x00 0x00
0x9D = 0x01 0x00 0x66 0x07 0x00 0x00
0x98 = 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x66 0x07 0x00 0x00 0xB3 0x00 0x00 0x00 0x20 0x00 0x00 0x00
0x9D = 0x01 0x00 0x66 0x07 0x00 0x00
0x98 = 0x00 0x00 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x66 0x07 0x00 0x00 0xB3 0x00 0x00 0x00 0x20 0x00 0x00 0x00
0x9D = 0x01 0x00 0x66 0x07 0x00 0x00
0x98 = 0x00 0x00 0x01 0x04 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x66 0x07 0x00 0x00 0xB3 0x00 0x00 0x00 0x20 0x00 0x00 0x00
0x92 = 0x00 0x00 0x00 0x00 0x00
0x90 = 0x03
0x94 = 0x01
0x05 = 0x040x9E = 0x00 0xFF
This process includes:
- An RGB LED current adjustment
- A number of illumination time validations (the illumination time is changed dynamically and so can have many different possible values, so we make use of the validation command to decide upon our final illumination time values for the pattern sequence table).
A number of internal pattern table sequence writes.
- Trigger input/output configuration.
- Activation of internal pattern streaming mode.
The inconsistent behavior I have observed is that the internal pattern sequence will sometimes come up completely incorrectly. Most of the time it works, however some of the time the patterns simply aren't played (I see fully illuminated rectangles rather than columns matching my 1D pattern bitmap) or it appears to be somewhat darker than usual, or some columns within a pattern will be missing while others are fine. Other times I've seen very odd behavior, such as the splash screen from the other operating mode appearing within the sequence.
The problematic behavior happens maybe once in every ten operating mode transitions, and each time it remains consistent until the controller is placed back in the opposite mode (splash screen vs. internal pattern stream) and then returned to the original mode, a process which pushes all of the above I2C register writes to the controller once again.
Is there anything we're doing configuration-wise that looks problematic here?