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: No I2C response using a custom board with stock firmware

Part Number: DLPC3435
Other Parts Discussed in Thread: DLPA2005, , TIDA-00325

Recently we developed our own board to utilize the DLPC3435 and DLPA2005 chips, to work with a Raspberry PI CM4.
This prototype board is nearly a 1:1 match of the example schematic for the TIDA-00325 (https://www.ti.com/lit/pdf/tidrbl3)

After some debugging and small revisions, we managed to get the first board to operate properly, and works well with the PI. Some revisions that were needed, include removing some unnecessary ferrite beads, and removing two resistors on SPI which were pulling to ground on CLK and MISO.  
Programming each board has been possible, and validated, using the stock firmware (I have not looked into custom firmware yet). The Boot up procedure also seems valid for each board with HOST_IRQ going high during boot, then low to signal completion, as well as RESETZ going high during the boot process. Each prototype will turn on and display the default checkerboard pattern.
 
However, for every board except for our first, the i2C is not responding from the DLPC3435 when probed.
I have specific questions that might help me address why this is happening and solve the problem.

1a) Does having the checkerboard pattern display, validate that the firmware is properly flashed, and that the system has booted properly?

1b) Is the Checkerboard pattern generated by the firmware on the Flash? Or is it generated by the hardware?

2) Aside from firmware, are there any reasons i2C would not initialize?

As a somewhat related secondary question

3) Is there source code I can change, or ways to customize the firmware outside of just uploading our own flash images?

Any help would be greatly appreciated. Thank you.

  • Hello User,

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

    Are you using the Raspberry Pi to control the I2C lines? If so, you may want to consider confirming that the correct I2C bus is chosen for the Raspberry Pi. If not, what are you using as an I2C bridge?

    To address your questions please see my responses in black to your questions in blue:

    1a) Does having the checkerboard pattern display, validate that the firmware is properly flashed, and that the system has booted properly?

    This is a good indicator. Ultimately the HOST_IRQ would be the best metric for determining if the system has completed initialization. Since you have mentioned that this drives high and then low, it is fairly safe to say that the boot process is complete and that the flash image is correct.  

    1b) Is the Checkerboard pattern generated by the firmware on the Flash? Or is it generated by the hardware?

    The checkerboard pattern is generated by the flash firmware image.

    2) Aside from firmware, are there any reasons i2C would not initialize?

    Yes, there are a few. Some common reasons for I2C failure are:

    1. Poor hardware connection, including a lack of pull-up resistors
    2. Contention for the I2C bus in the case of multiple devices sharing the bus
    3. Using a bus speed too high for the device. Our DLPCs typically work best with an I2C bus speed or 100 KHz.

    3) Is there source code I can change, or ways to customize the firmware outside of just uploading our own flash images?

    Firmware images can be customizing through the LightCrafterTm Display GUI in the Update Flash Image wizard under the firmware tab. Is there anything you are hoping to have your customized image do?

    Is there any difference between your first, working board and these new boards? How is the Pi processor connected?

    Kind regards,

    Austin

  • Thank you Austin for your fast and very thorough response.

    Knowing it's not a firmware issue, I double checked the pull-ups on the boards. It appears our CM populated the board incorrectly with 0 Ohm pull-ups instead of 4.7k. This solved the issue for us. Thank you.

    The reason my initial board was working was that I had removed these pull-ups when trying to naively debug our board at first. And then replaced them when configuring the pi to work correctly. I never realized the resistors were the wrong value.

    As for custom firmware, there was nothing specific. Mostly that reading the source code would give me some insight into the value returned when reading the max current, and how to associate that to an actual Amp value. 

    I will look into the light crafter display software. 

    Thanks again for the massive help.

  • You are very welcome. I am glad this has been resolved for you.

    Please feel free to post with any additional questions you may have in the future, and thank you for your business!

    Regards,

    Austin