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.

DLPC3435: Never-ending boot cycle loop on custom board with DLP projector

Part Number: DLPC3435
Other Parts Discussed in Thread: DLPA2005, , DLPC3430

Hi there, and thanks in advance for the help.

General Info:
We have developed our Beta iteration of a PCB that's slated to go into production this month. The board uses a DLPC3435 and DLPA2005 chipset, and is based off a working prototype board with a few changes. Our board uses a Pi, with a DPI configuration.

The DLPC doesn't seem to complete it's boot, and continues to reset about 4 times a second.

Sequence and tests so far:
The DLPA seems to be operating properly, all rails seem to match specs in the datasheet.
The DLPC does request firmware from the external flash via the SPI bus. There is data going back and forth on the MISO and MOSI lines
Scoping the DLP_RESET pin, it seems to drop to ground 4 times a second. About 239ms Up and approx 11ms down, repeating.
DLP_HOST_IRQ seems to follow the DLP_RESET pin, and drop. However it stays lower for longer as we do not have an external pullup on that pin.

Changes since last board:
1) Flash chip now runs on 1v8, and is now the maximum size specified by DLPC datasheet (Previously it was larger than max :S)
2) There is no external pull up on HOST_IRQ. Adding one does not change the testing
3) DSI is connected to the pi with 0ohm resistors. Previously we did not have this option but wanted to see if we could develop the drivers for this.
4) GPIO_08 is now connected to the Pi's GPIO's for programmatic control of the projector. Previously this was hardwired in to the power switch.

Things that are the same:
1) Same Processor and code
2) Same firmware
3) Same projector and DMD (Uploaded and verified)


  • Hello User,

    Welcome to the E2E forum and thank you for your interest in DLP® technology!

    Please allow the team to look into on how we can assistant here and get back to you in a few days.



  • Hello Drew,

    Have you seen the DLP_RESET issue on your previous custom boards?

    Base on you changes since last board, I have few questions:

    2) What is the value of the pull-up resistor you added on HOST_IRQ for testing? 

    4) Why did you choose GPIO_8 to connect to the Raspberry Pi? Based on the reference design TIDA-00325, GPIO_8 on DLPC3435 is connected to PROJ_ON which is the main power supplier for the chipset. I don't think you should change the connections.



  • Hi Lori, thank you for your response. 

    2) The Pull-up I tried was 4.7K and also 10K
    4) The datasheet has PROJ_ON used as a control signal to turn the DLPA and DLPC on. Please see Page 48, Figure 8.2 in the DLPC3435 datasheet. 
    PROJ_ON is connected to the host controller as a signal

  • Hi Drew,

    I suspect that the DLP_RESET signal that you mention here is the RESET_Z signal from the DLPA2005 to the DLPC3430. Is this the case? If so the DLPA2005 is detecting a fault and resetting the controller, resulting in the continuous power cycling that you are observing. If you are certain that the power rails are behaving correctly, I recommend checking for UVLO (under voltage lockout) and OVP (over voltage protection). UVLO can be checked at VINA of the DLPA2005. VLED should be measured to check against conditions for OVP. These are more thoroughly explained in the DLPA2005 datasheet. Please let us know if these voltages are outside of range.

    Since you mentioned it, what is the plan for DSI? If this you are intending to use DSI for video feed to the DLPC3435, you will run into issues. The DLPC3430 supports DSI, but the DLPC3435 does not.



  • Thanks Austin,
    I will double check those rails, but I believe we looked at this. I'll get back to you.
    We're not currently using DSI, we still using parallel. The board was designed so we could make the transition and support pin compatible chips like the DLPC3430. However, that being said, we have the DSI lines connected to the PI through 0ohms. I will remove those jumpers and leave the traces NC.

  • Austin,

    Thanks for the help.
    Removed all the jumpers for DSI, with no change.

    UVLO appears to be fine.
    - VINA is 4.8V when RESET_Z is HIGH and the DMD is connected.
    - Although there does seem to be a bit of a voltage drop compare to toggling it on when the DMD is not connected. The voltage on that rail is always 4.96V when RESET_Z is LOW, or when there is no DMD and RESET_Z is HIGH.

    OVP also appears ok.
    - VLED stays at 0 regardless of any state

  • Drew,

    Thank you for the update. You are right that UVLO doesn't seem as suspicious. VINA would likely have to drop to less than 3V to trip UVLO.

    The controller will need to be connected to the DMD to finish initialization. I doubt this is what is causing the issue since it sounds like you have been testing with the DMD connected and disconnected with the same result, but it is worth mentioning.

    Are any other voltages seen on the power sequence diagrams on the DLPA2005 datasheet (see page 13 and 14) not coming up as expected? It has been stated previously that the rails are within spec, but if VLED is not coming up I would like to check if others are also not driving as expected.

    Additionally, are LED's connected to the system when booting?



  • Hi Austin,
    We have two prototype boards, and the second board shows the same issues with the repeated boot cycle.
    However on this board the VINA stays consistent at 5.04V, regardless of RESET_Z being high or low.

    The DMD and the LEDs are connected. It's worth noting that we did test without the DMD and LEDs, and the boot sequence doesn't repeat, but as expected, HOST_IRQ never goes low as there is no DMD

    The rails seem normal up until the glitch. I scoped each one and they match to what's on page 13. I've attached a screenshot of what I'm seeing.
    One thing to note, is that RESETZ drops AFTER VBIAS, VOFS, and VRST reset.

  • Austin,
    We were able to debug the problem, We had too much bulk capacitance on those lines (2 x 10uf). The data sheet specifies a min of 220nf, but doesn't specify a maximum. Remove the bulk has solved the issue