This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dear TI DLP support staff,
I am developing simple pico projector system without DM365 and FPGA modifiying original LightCrafter design.
DLPC300 read parameters from SPI FLASH ROM successfully.
But function "dlpc300_main_configure()", BLUE_EN, GREEN_EN, RED_EN signal are emitted only 9 pulses then the signals stops. So LEDs do not light. RPWM, GPWM, BPWM signals are emitted correctly.
How can I solve this problem?
Please reply.
Best regards,
Alex
Alex,
I suspect the problem with dlpc300_main_configure() I2C writes are not successful.
Look at the MSP430 source code dlpc300.c
uint08 dlpc300_main_configure(void)
/**
* Common dlpc300 setup for all input types. This must be executed first
* before attempting to display an image.
*
* @return none
*
*/
{
uint08 EnableSafetyChecks = TRUE;
// enable LEDs
write_dlpc300_i2c(DLPC300_DEV_ADDR, LED_CONTROL, 0x0D, 1);
// write the software version number to a spare register field
write_dlpc300_i2c(DLPC300_DEV_ADDR, MISC_REG, MAJOR<<8 | MINOR, 1);
// enable HW Test Points
// HW TST PT 3 = Red LED
// HW TST PT 2 = INV PAT
// HW TST PT 1 = BUF_SWAP
// HW TST PT 0 = RD_BUF0
write_dlpc300_i2c(DLPC300_DEV_ADDR, HW_TEST_P1, 0x14151624, 1);
// enable HW Test Points
// HW TST PT 7 = RD_BUF1
// HW TST PT 6 = CAM_TRIG
// HW TST PT 5 = Blue LED
// HW TST PT 4 = Green LED
write_dlpc300_i2c(DLPC300_DEV_ADDR, HW_TEST_P2, 0x25111213, 1);
....
....
}
Without successful I2C configuration settings of above register of DLPC300 the LED_EN signals will NOT be enable.
So suggestion - check the I2C writes are successful.
Look into dlpc300_LightCrafter.c
void write_dlpc300_i2c(uint08 addr, uint08 subaddr, uint32 data, uint08 verify)
{
uint32 read_data;
uint08 num_written;
uint08 i2c_array[5];
i2c_array[0] = subaddr;
i2c_array[1] = (uint08) (data>>24);
i2c_array[2] = (uint08) (data>>16);
i2c_array[3] = (uint08) (data>>8);
i2c_array[4] = (uint08) data;
i2c_master_polled_write(addr, i2c_array, 5, &num_written, 30);
if ( verify ) {
read_dlpc300_i2c(addr, subaddr, &read_data);
}
}
You can verify data == read_data. this will confirm successful transaction on the I2C bus.
Regards,
Sanjeev
Sanjeev,
Thank you very much for your quick reply.
As your suggestion, I changed the function "write_dlpc300_i2c()" as below.
void write_dlpc300_i2c(uint08 addr, uint08 subaddr, uint32 data, uint08 verify)
{
uint32 write_data; //DebugAlex131027
uint32 read_data;
uint08 num_written;
uint08 i2c_array[5];
write_data = data; //DebugAlex131027
i2c_array[0] = subaddr;
i2c_array[1] = (uint08) (data>>24);
i2c_array[2] = (uint08) (data>>16);
i2c_array[3] = (uint08) (data>>8);
i2c_array[4] = (uint08) data;
i2c_master_polled_write(addr, i2c_array, 5, &num_written, 30);
if ( verify ) {
read_dlpc300_i2c(addr, subaddr, &read_data);
if (write_data != read_data) //DebugAlex131027
blink6(); //DebugAlex131027
}
}
But result was no read_data mismatch.
Could you advise other reason?
Best regards,
Alex
Alex,
OK.
Without the LED_EN signals coming can you look at the DMD and see if the splash images are displayed on the DMD? You can see in the function uint08 dlpc300_main_configure(void) splash images are displayed. Let me know the result you see on the DMD.
If NO image is displayed then as per the LED Driver schematics look at the DLPC300 I/O B8 (POWERGOOD) signal stability. If it is not continuously HIGH then it would cause DLPC300 to enter into fault protection mode and it forces DMD into DMD PARK state.
Can you also read registers
1. Interrupt Status Register [0x00/0x01]
2. Main Status Register [0x03]
3. Sequence control [0x82]
4. Sequence Vector Setup [0x83]
Regards,
Sanjeev
Hi Sanjeev,
I checked DMD device directly then 4 splash images displayed for 5 seconds each.
So DMD control seems successful.
DLPC300 POWERGOOD (B8) input signal is continuously HIGH.
I checked the registers values before / after function call line "dlpc300_config_splash( 1 ); " in function dlpc300_main_confgure() as below.
The result was :
Interrupt Status Register 0x00 : 0
Interrupt Statul Rgesiter 0x01 : 0
MAIN_STATUS : 2186 (0x88A)
SEQ_CONTROL : 1
SEQ_VECTOR : 512 (0x200)
Before and after dlpc300_config_splash(1) are the same values.
Please give me advice.
Best regards,
Alex
Hi Alex,
The status register shows everything is proper, I don't see the reason on why the LED_EN signals go after sometime.
As per driver schematics,
1. ensure the signals are pulldown to GND via 10K resistor.
2. Check LED_ENABLE (A11) is not going LOW.
3. If the DLPC300 I/Os B5, A7, C8 LED_RED_EN, LED_GRN_EN and LED_BLU_EN are connected to LED driver logic then disconnect the signals going to driver circuit. Now probe the signals if it is modulating. If it is then there should be problem with LED driver logic.
Regards,
Sanjeev
Sanjeev,
I checked your suggestions.
1. The signals are pulled down via 10K resistors.
2. LED_ENABLE (A11) input is continuously HIGH.
3. DLPC300 B5, A7, C8 (LED_xxx_EN) are connected to SN74AVC4T245RSV "A"s and 245's "DIR"s are HIGH.
so 245's "A"s are Hig-Z. Similar signals xxx_PWM are emitted from 245's "B"s correctly.
Therefore LED driver logic is correct I think.
Do you have further suggestion?
I am waiting for your answer.
Please help me.
Regards,
Alex
Sanjeev,
By the DLPC300 data sheet C8(BLUE_EN), A7(GREEN_EN), B5(RED_EN) pins are input when optional FPGA is used.
My design does not use FPGA, so I wonder SPI FLASH memory data DLPR300PROM_v1.0.bin is not correct for w/o FPGA design?
Or should I change the firmware of MSP430 not to use FPGA?
Please reply.
Regards,
Alex
Alex,
The SPI FLASH memory data DLPR300PROM_v1.0 can be used for both with and without FPGA design.
I still suspect problem with your h/w design of routing the LED_EN signal.
You should see the LED_EN signals modulating while the splash screens are displayed on the DMD.
I am suspecting you misunderstand about the LED_EN signal as I/P or O/P while referring to schematics. These signals are strictly O/P only. Note in the Driver schematics R35, R36, R37 resistors are not populated. What it means is TSTPT3/4/5 from DLPC300 going into the optional FPGA and returned as LED_EN signals, now with the R31, R32 and R33 installed, the signals from FPGA are going as LED_EN signals to the driver circuit.
I think you pointing to DLPC300 datasheet was timely helpful. For the LED_EN signals it is clearly mentioned as the signals be pulled to GND via 10K only when optional FPGA used. Which is NOT in your case.
I suggest to try the following
1. Remove LED_EN pull-down resistors, R22 to R29. Now check if the signals appear.
2. Even if you don't see the signals, just remove SN74AVC4T245 bus txr chip and probe the signals directly.
You should start observing signal at least now.
Regards,
Sanjeev
Sanjeev,
Thanks for your reply.
I understood SPI FLASH memory data DLPR300PROM_v1.0 is available for both w/ and w/o FPGA design.
As you mentioned my description "C8(BLUE_EN), A7(GREEN_EN), B5(RED_EN) pins are input when optional FPGA is used." was wrong. Actually I checked original LightCrafter's RED_EN(B5), GREEN_EN(A7), BLUE_EN(C8) signals are modulating.
But in my design FPGA is not used , so I connected RED_EN, GREEN_EN, BLUE_EN signals to LED driver's input SN74AVC4T245 "A" pins.
So the problem is pull down resistors as you told.
In DLPC300 data sheet RED_EN(B5), GREEN_EN(A7), BLUE_EN(C8) pins are written "When used with the optional FPGA, this signal should be pulled down to ground through an external register.". It means in my w/o FPGA design, these pull down resistors should NOT be mounted. So I will remove R26, R27, R28 and check if RED_EN, GREEN_EN, BLUE_EN signals modulate.
But in the data sheet OUTPUT_TRIGGER(N9), PATTERN_INVERT(C7), RD_BUF0(B6), BUFFER_SWAP(A8) pins are written "When not used with an optional FPGA, this signal should be pulled down to ground through an external resistor". And RD_BUF1/I2C_ADDR_SEL(R9) pin is written "If I2C_ADDR_SEL signal is pulled-low, then the DLPC300's I2C slave address is 1Bh.". So I think I should not remove R22, R23, R24, R28, R29.
How do you think?
Please reply.
Regards,
Alex
Sanjeev,
Thanks for you reply.
I understood your advice. But I have one question.
You wrote "Remove LED_EN pull-down resistors, R22 to R29.".
But accurately "Remove LED_EN pull-down resistors, R26, R27, R28.".
Is that right?
I mean R22, R23, R24, R28, R29 should not be removed.
Please reply.
Regards,
Alex
Sanjeev,
I made a mistake above message.
Wrong : But accurately "Remove LED_EN pull-down resistors, R26, R27, R28".
Correct : But accurately "Remove LED_EN pull-down resistors, R25, R26, R27".
I am sorry.
Regards,
Alex
Alex,
It depends on what your doing with other signals. If they are not used then its OK to keep them GND.
Yes, for debugging remove R25, R26 and R27.
Regards,
Sanjeev
Sanjeev,
Thank you for your answer.
Finally it worked!
I must apologize that the reason was power supply current limit.
During debug I limited the current as low as possible to prevent the board crush.
So LEDs could not light. Actually I don't know why LED_EN signal stopped...
Anyway now each LED_EN signal is modulating and display correctly.
For reference, R25, R26, R27 removed board and not removed board are working either.
I appreciate your kind advice so much.
I continue for further test of this board.
If I meet next problem, I will make a question again (on another thread).
Best regards,
Alex
Alex,
I am glad that you are able to resolve the problem. You are welcome. I think this discussion will be important for others to debug step-by-step.
I am not able to figure-out how the low-current stops driving the LED_EN signals. I must warn driving devices with low current beyond the spec might cause device malfunction.
Sure, you can post new thread.
If you don't mind can you please let us know details about product and your plans on developing the product? If you don't wish to share in the forum. You can send details via Friend request.
Regards,
Sanjeev