DLPC1438: Boot failure - HOST_IRQ stays high

Hi Woo Jun Kim,

Welcome to DLP forum and thank you for your interest in DLP technology.

Our team will look into this and get to you by middle of this week.

Regards,

Akhil

For your reference, I checked the timing diagram in the datasheet DLPA2005 Fig.3(p13).

It looks OK except RESETZ.(red=PROJ_ON, blue=RESETZ)

RESETZ goes high after 10ms from PROJ_ON high but it doesn't go high directly and it's voltage level is higher than 1.8V.

Also V6V is 0V and I am not using FPGA(same when FPGA_RDY is high or low).

I am not sure this is the cause of the boot failure, but just want to make sure.

Hello,

Woo Jun Kim said:

I guess DLPC1438 tries to load firmware from flash before checking/configuring chipsets(DLPA2005 and DLP301S), is it true?

If so, the problem may be related to firmware loading procedure and need to be solved before double-checking my board.

Yes, this is true.

Woo Jun Kim said:

1. When powering up(1.8V, 1.1V), does CSZ pin of SPI0 goes high and then low to try communicate with flash memory regardless of all other possible problems?

Yes, the CSZ line will go high and then low as a very early step in the initialization process. The line will be pulled high due to the pull up resistor on the line. The DLPC will pull CSZ low as it attempts to access the SPI flash data.

Woo Jun Kim said:

- SPI host adapter and software by Total Phase: there is no option for .img extension in Flash Center.

The .img files will appear in TotalPhase's Flash Center if the file type is set to Binary Files.

This is the methodology that we commonly used.

I will look into why there is a difference in extension for our firmware, thought .img is technically a binary file. It should be accepted by most flash programmers.

Regards,

Austin

Thank you for your reply.

1. Can you also check the RESETZ waveform, please?

2. When I open FWSel_DLPC1438_DLPA2005_pm1_i2c0x36_v9p5p1.img using Flash Center, it looks like below.

And same file using CH341A Programmer which is very common EEPROM/FLASH writer.

They look same.

If they are different as mentioned in the previous link, it means Flash Center may do something before writing to flash, which is hard to believe.

If you are saying .img is exactly same as .bin, then I suggest that TI should release all firmware with .bin or .hex extension, just like FPGA firmware(.hex).

People here keep asking same questions and there is no need to cause confusion with just file extension.

If not, please make .bin instead of .img.

Hello User,

The team can look into the expected system behavior requested above. Thank you for your patience.

Best,

John

Hello User,

Woo Jun Kim said:

If you are saying .img is exactly same as .bin, then I suggest that TI should release all firmware with .bin or .hex extension, just like FPGA firmware(.hex).

People here keep asking same questions and there is no need to cause confusion with just file extension

Thank you for this note. I have been discussing this possibility with my team. Though there is no functional difference between the .bin and .img, we have decided to keep this naming convention since this allows for our internal software structure and they are flash image files. I will edit the line that you have reference above from the link to avoid any future confusion.

The below plot of ResetZ was taken with a DLPC1438, DLPA2005 configuration wherein the system booted properly.

The waveform rises from ~0.4V to ~1.7V in 3.2ms without a step.

ResetZ appears that it may be floating. Is there a buffer on ResetZ for your design? If so, please try probing ResetZ on the DLPA side before the buffer? How is ResetZ being pulled up to 1.8V? The 1.8V rail is coming from the DLPA?

Is the ResetZ signal cycling? Is it possible to replace the DMD with another to test if the DMD has been damaged?

It appears that you were successful in loading the firmware into a flash programmer. Were you able to re-flash the system? If so, was there any change in behavior?

Regards,

Austin

Hi.

I appreciate your detailed answer.

OK. The .img extension is just another name name of .bin, which TI prefers.

When I write and read the firmware, they are same and same behavior.

So we are checking our board and will redesign for easier test.

Thank you.

Hello User,

You are welcome.

Please let us know if we can be of further assistance.

Regards,

Austin