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.

DLPC3439: Request for more debugging info

Part Number: DLPC3439
Other Parts Discussed in Thread: DLP4710, , DLPA3005, TIDA-01226, DLPDLCR4710EVM-G2

I have a custom projector which uses the DLP4710, DLPA3005 and a pair of DLPC3439 controllers, similar to the TIDA-01226 ref design. There's no MSP430, HDMI receiver, or USB interface, a different micro is there to signal projector_on, monitor status pins, and talk I2C. Main power is 12VDC, and the interface voltage and flash voltage are both 3.3v. The mirror signals are wired according to option1. It will eventually have RGB24 parallel input, but for now those parallel input lines are all pulled down to ground with 7.8K resistors.

When the projector_on signal is given, the DLPA3005 produces the proper 1.1V, 1.8V, 2.5V and 3.3V rails, and the RESETZ, INTZ, and master and slave controller IRQ signals all go high, followed by a burst of activity (about 33msecs) on both of the controllers' flash SPI bus ports. Then nothing. The power rails that were up are still up and stable, but no other rails come up and the IRQ lines never fall. Nothing gets hot. If I remove the flash chips, they verify correctly in a programmer. Both controllers have a good stable clock from a shared oscillator, all 3 LEDs are present, the JTAG reset is pulled down on both controllers as in the reference design, and the SPI signals between master controller and power manager are pulled with same resistor arrangements as in the ref design.

As a further sanity check, I removed the DLP controllers and mirror device from one circuit board and wired a micro to the SPI bus connected to the DLPA3005. After signalling projector_on, I was able to easily access all its documented registers, which all started at the proper default values. That device seems to be behaving properly, and its SPI bus is clearly properly wired.

Could you please provide more information about what other things I should check, and whose failure would cause the controller boot process to stall?Are you able to provide a much finer-resolution explanation of the boot process and what exactly gets checked, in what sequence, and with what consequences if conditions are wrong?

Does the DMD itself need to be installed for the boot to complete, or can some testing be done without it? (I've been testing with it, but they're rare and expensive right now). If there was a problem with the interposer or DMD would the controllers complete their boot, or would they abort the boot?

I'm a bit concerned that there's no easy way to verify that all the signals are getting to the DMD through the interposer, is this ever generally an issue?

Do your devices log failed boot diagnostics into the serial flash devices, and if so, can that be extracted and analyzed? Is there any debugging ability available via the controller JTAG ports?

I'd sure appreciate any further tips you can provide.

  • Hello User,

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

    Yes, if the controller does not find the DMD and PMIC that matches with the firmware image that the controller has flashed, it will not complete its initialization process.

    Unfortunately, there is currently no debug tool available for boot issues. However, it can be helpful to observe the power-up timings that you are seeing on your board. You have mentioned that INTZ and RESETZ drive high. Are you seeing any activity on DMD_VOFFSET? This might indicate that the controller is not detecting the DMD.

    Do you have a DLPDLCR4710EVM-G2 available? If so, it may be helpful to attempt to connect your custom board to the optical engine on the EVM. Likewise, it would be helpful to see if the EVM will boot when connected to the optical engine on your custom board.

    Kind regards,
    Austin

  • Thanks for the reply.

    I am running the "DLPC3439_DLPA3005_pm1_i2c0x36_v7p7p1" firmware, two DLPC3439CZEZ controllers, a DLPA3005D, and using DLP4710AFQL mirror.

    No, there are never any voltages present on VOFFSET, VRESET, or VBIAS, which I presumed was the case because the master 3439 chip was stalling before telling the 3005 to power the mirror. Was my assumption an error, and is the 3005 supposed to independently bring-up these three mirror supplies? If that's the case, does somebody there at TI know why the 3005, which seems otherwise happy and healthy, would fail to provide those rails?

    Is there any document that lists the activity that should be present on the SPI bus between the master controller and the 3005? How about for the I2C chatter between master and slave controllers? I would think that (sequence and timing of sent and received bytes, though not perhaps their meaning ) could be disclosed by TI, since anybody with a working projector and a logic analyzer could sniff it out, but it would be helpful to somebody debugging a new projector to be able to observe that this set of SPI and I2C transactions occur, and without being corrupted. Additionally, a developer could submit what he observed to TI and TI might be able to gain more info to help them help a developer.

    What exactly does the pair of controllers need to see on the DMD? Does it only look at certain pins or does it do some phase training on all the pairs or some such thing? (I am wandering what I should look for)

    Also, do both controllers try talking to it, or is this something the master only does?

    Does the boot process stall if the two controllers are not talking to each other? Do they also test the path between them using GPIO14-19?

    Is there any way for me to know what, exactly, made the controller or controllers unhappy enough to not finish starting? Clearly the chips themselves know, since their code has detected some situation and decided to stall. It seems odd that there might be no mechanism to report the reason for such a stall to the outside world with a code encoded as pulses on a test pin or something.

    If the system is in some way unhappy with the LEDs, would this be observable with a brief illumination before a shutdown, or would the decision to give up be so quick that the LEDs would never illuminate? I'm wondering if I would see with my eyeball, or would need to probe that with a scope, and if so, if it would look like a serious attempt to energize or more like a glitch or noise spike.

    No, I do not have an EVM for the 4710, and I do not have compatible interfaces anyway, so the best I'd be able to do is use one to observe voltages and timing and swap-out firmware images to verify the code (something that *should* be unnecessary).

    It would be nice if your team had written a firmware image for bringing-up projectors, with perhaps the ability of a host to tap into and talk to the two controllers independently over I2C to command tests of the controllers, and get results, then flash production firmware... ah, well , perhaps your team might consider it on future chipsets.

  • Hello User,

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

    Allow us more time to look over the behavior that you have reported in this case. The team will have to look into a debug process for you to get a better understanding of where this stems from.

    Regards,

    John

  • Thanks for the assistance. Your previous comments were helpful.

    Had an issue with the 1.8V supply to the DMD. Now that the DMD gets 1.8V on both Vdd and Vddi, the following occurs:

    VOFFSET rises to +10V

    then

    VBIAS rises to +18V and VRESET falls to -14V

    Then the master half of the DMD briefly shows a coarse checkerboard, and the LEDs flash very briefly (too brief for my eyes to see which), with LED_SEL_0 and LED_SEL_1 pins apparently signalling GREEN, then NONE, before VOFFSET, VBIAS, and VRESET go back to 0V.

    Should I be seeing the pattern appear on only the master half as it is, both halves at once, or should the slave side do this after the master side?

    Could you give me some clues on where to further look for issues?

    Is there any way to know if the master & slave controllers are communicating well and id the slave is able to see the DMD?

  • Hi Tim,

    Can you please describe what this sentence means "with LED_SEL_0 and LED_SEL_1 pins apparently signaling GREEN, then NONE"?

    When you noticed VOFFSET, VBIAS, and VRESET drive low, what is the behavior of the signals INT_Z and RESET_Z? Do you see the Proj_on signal staying high? I think there might be a fault flag occur. 

    Also, I wonder how you program the two controllers on your custom board. Do you have two flashes and make sure you program them both?

    Regards,

    Lori 

  • LED_SEL_0 and LED_SEL_1 both low = NONE

    LED_SEL_0 low and LED_SEL_1 high = Green

    Proj_on is high, INT_Z is high, RESET_Z is low

    Each controller has its own identical SPI flash, programmed and verified with same firmware pre-soldering.

    Additional info:

    I can now talk to the master controller via I2C and my software (incomplete and not yet able to dump all register contents) reports the following:

    Flash Build Version: 7.7.1
    System Software Version: 4.2.2
    Controller Device ID: DLPC3439
    DMD Device ID:
      Identifier [OK]
      ByteCount  [OK]
      MsByte     [OK]
      Device [unknown][0x8A]

    Short Status:
      Application: [Main]
       Flash: [No Error]
      Flash Erase: [Complete]
       System: [No Error]
       Communication: [Error]
       System Init: [Complete]

    System Status:
       Watchdog: [No Timeout]
      Product Config: [No Error]
       Role: [Master]
      ASIC Config: [Dual]
       SpiFlashlessComm: [No Error]
       SpiFlashlessDatReq: [No Error]
      Sequence: [No Error]
      Sequence Abort: [No Error]
      BLU LED: [No Error]
       GRN LED: [No Error]
       RED LED: [No Error]
       BLU LED State: [On]
      GRN LED State: [On]
       RED LED State: [On]
       DMD Training: [No Error]
      DMD Interface: [No Error]
       DMD Device: [No Error]
    Comm Status:
      Byte5:
         Bus Timeout: [No Error]
         Invalid Param Count: [No Error]
        Read Cmd: [No Error]
        Flash Batch File: [No Error]
        Cmd Processing: [No Error]
        Invalid Cmd Param: [No Error]
        Invalid Command: [No Error]
    Byte6:
         I2C CMD Error OpCode: 0xEF
    Input Source: [Splash Screen]
    Test Pattern Selection:
       Test Pattern: Solid Field, Border Disabled
       Foreground Color: Black
       Background Color: Black
    System Temperature: +28.2c

    I am able to cycle through input source selections reliably and reliably dump this subset of controller registers, and see it holding the changes to the input source selection, so my host CPU's access to the master DLPC3439 seems solid.

    I was expecting to see the DMD identify with a 0x6B code (section 2.3.3.73.3 of T.I. doc DLPU035) but I get the 0x8A shown above. Is this because the DLP4710 DMD is newer than the doc? Can you verify that?

  • Hi Tim,

    Thank you for the information. 

    Please allow us some time to look into these behaviors and we will try to get back to you by the end of next week. 

    Regards,

    Lori 

  • Hi Tim,

    For your question, "I was expecting to see the DMD identify with a 0x6B code (section 2.3.3.73.3 of T.I. doc DLPU035) but I get the 0x8A shown above. Is this because the DLP4710 DMD is newer than the doc? Can you verify that?"

    Yes, the newer version of the DLP4710A DMD should be identified as 0x8A. We are planning to update the DLPC3439 Software Programmer's Guide.

    For the slave controller, I would suggest investigating the power going into the slave controller and the access from the slave controller to the SPI device. 

    Also, it would be good to compare the firmware that you pulled from the controller with the binary image you want to be by re-flashing the image. 

    With the correct behavior of the above things, the slave controller should come up with the beginning of the process. 

    Regards,

    Lori 

  • 1. Thanks for verifying that 0x8A is a valid code for the DLP4710A

    2. As indicated earlier, each DLPC3439 has its own spi flash. Each flash was programmed with the same image and verified in a programmer before being soldered down. Subsequently, each has been removed and new chips were programmed and verified and then soldered down. I do not think my problem involves the code or the SPI memories.

    My overall problem is that I have a system that starts up and then aborts partway through the startup process, and I lack the information that I would typically have to debug this situation. There is sparse documentation about the startup process, explaining the sequence of events that must occur for proper operation, what will cause the devices to abort, and what that will look like, etc.

    Example: I briefly see a checkerboard pattern on the master controller's half of the DMD, but I have no information on if this is normal.

    [a] Is this normal?

    [b] Should it occur on both halves?

    [c] If so, then should it appear on both halves in some sequence or simultaneously, etc?

    Because there is so little documented about the startup, I do not know if the DMD is unhappy and is causing the shutdown, or if the slave controller is unhappy and directly causing the shutdown, or if the slave controller is unhappy and signalling the master which then causes the shutdown, or if the master controller is unhappy and causing the shutdown, or if the DLPA3005 is unhappy and causing the shutdown.

    Can your people give me at least some clues about what to look for and even which components are capable of causing the shutdown?

    Is there any way to talk through the master controller via I2C and gain access to the registers of the DLPA3005 to gain additional insight?

    If not, is it safe to tap into the SPI bus between the master controller and the DLPA3005 to get a look at those registers?

    Is there any way for me to know if the master and slave controllers are communicating properly with each other?

    Is it safe to attach another micro to the I2C bus between them and try to talk to the slave controller directly over the I2C bus?

    The master controller must be able to communicate with the DMD other than just sending it pixels, since it can identify the specific mirror type. Does the slave also do this? Is it possible the slave is having problems seeing the DMD and therefor is signalling an abort?

    Something is very rapidly deciding to shutoff the VOFFSET, VBIAS, and VRESET rails, but I lack basic information about which component is capable of doing it, whether any devices are capable of requesting other devices shutdown, which is likely doing it, and what conditions would lead one of the devices to do it, etc. The rest of the system remains stable and I can communicate with the master controller over I2C, as the info I provided above illustrates, but the device does not seem to have a capability to tell me if it has ordered a shutdown, or if the slave or the mirror has requested a shutdown, or if it is having problems talking to the slave or the mirror.

    I find it interesting that, after the three rails shutoff, and I query the master 3439, it tells me (via System Status read) that all 3 LEDs are on, and without error, yet no LEDs are lit. This is why I would like to be able to poll the DLPA3005 registers, even in read-only mode; it would be more information.

    Also, I see that the System Status read says that the DMD interface and training are without error. Does this mean the DMD is talking properly to both controllers or does it only apply to the master? Is there a way with this chipset to see more training data so I can see how much margin I have?

    I'm looking at everything I can, but I am doing it with a virtual blindfold on. Anything you can do to lift the blindfold and provide a little more illumination as to what I should be looking at, what is considered normal, what would trigger various failure modes, etc would be very helpful.

  • Hi Tim,

    Please see the responses below:

    Example: I briefly see a checkerboard pattern on the master controller's half of the DMD, but I have no information on if this is normal.

    [a] Is this normal?

    [b] Should it occur on both halves?

    [c] If so, then should it appear on both halves in some sequence or simultaneously, etc?,

    A: It is normal, and the both dual controllers should boot up simultaneously. 

    Because there is so little documented about the startup, I do not know if the DMD is unhappy and is causing the shutdown, or if the slave controller is unhappy and directly causing the shutdown, or if the slave controller is unhappy and signalling the master which then causes the shutdown, or if the master controller is unhappy and causing the shutdown, or if the DLPA3005 is unhappy and causing the shutdown.

    Can your people give me at least some clues about what to look for and even which components are capable of causing the shutdown?

    A: You mentioned that the INT_Z signal is keeping high, then I think the trigger is not cased by the DLPA3005. If there is an interrupt event on the DLPA3005, then the INT_Z will pull down. Please refer to the DLPA3005 Datasheet for more information. Section 7.5.2 describes the Interrupt and Section 9. shows the power up/down diagrams. 

    You mentioned on your original post that the both HOST_IRQ lines never fall, are these HOST_IRQ lines still high after you fixed the power supply issue go to the DMD?

    If you can see that the HOST_IRQ lines are keeping high, this indicates that the controllers have not finished initialization. 

    It would be good to check if the controllers are able to access the SPI bus and if the flash is loaded properly. In your case, it might need to check the slave controller. Also, it would be good to check with the oscillator between the controllers if you have it in your design. 

    Is there any way to talk through the master controller via I2C and gain access to the registers of the DLPA3005 to gain additional insight?

    If not, is it safe to tap into the SPI bus between the master controller and the DLPA3005 to get a look at those registers?

    A: Yes, it's possible. However, if the HOST_IRQ is high, then I would suggest to debug this situation as first step. 

    You may want to refer to the DLPC3439 Software Programmer's Guide to get more information on the registers.

    Is there any way for me to know if the master and slave controllers are communicating properly with each other?

    A: Yes, it's possible, but it would be good to look at the SPI bus between the controller and the flash. 

    Is it safe to attach another micro to the I2C bus between them and try to talk to the slave controller directly over the I2C bus?

    A: I think it dese not work well until the system has finished initialization. 

    The master controller must be able to communicate with the DMD other than just sending it pixels, since it can identify the specific mirror type. Does the slave also do this? Is it possible the slave is having problems seeing the DMD and therefor is signalling an abort?

    A: Yes, the slave also does. Yes, it's possible. 

    I find it interesting that, after the three rails shutoff, and I query the master 3439, it tells me (via System Status read) that all 3 LEDs are on, and without error, yet no LEDs are lit. This is why I would like to be able to poll the DLPA3005 registers, even in read-only mode; it would be more information.

    Also, I see that the System Status read says that the DMD interface and training are without error. Does this mean the DMD is talking properly to both controllers or does it only apply to the master? Is there a way with this chipset to see more training data so I can see how much margin I have?

    A: It's possible that the controller has the LEDs enabled and the System Status read back as the LEDs are on, but the LEDs might not necessary to be visible ON. 

    Depending on your description, it seems like only master controller is communicated properly. 

    Also, is it possible to provide the schematic of your custom projector? I've sent you the friend request, you can use the private message to send me the schematic. 

  • Thanks for those answers.

    Sorry, but 11 days ago when I told you I had found and fixed a problem with my 1.8V rail to the DMD I intended, but clearly failed, to explicitly tell you that in additions to the INTZ and RESTEZ lines behaving properly, the INTs from the master and slave controllers were also behaving. At that point, I was able to start communicating with the master over I2C. My apologies for not being explicit about the INT pins.

    After I order the projector on, INTZ, M_IRQ, S_IRQ,and  RSTZ rise.

    Then S_IRQ (slave's IRQ) falls (which I presume means the slave is booted)

    Then M_IRQ (master's IRQ) falls

    Then INTZ falls

    some time after that ( I have not measured it yet, my host's software sees it) INT_Z rises (probably after the checkerboard appears on the master half of the DMD and the LEDs briefly flash on). The master controller remains running properly and I can access it via I2C, which is how I dumped all the info from it starting 10 days ago.

    I really need to get the brief-flash-then-shutdown issue resolved, and should have been able to resolve it long ago if I'd been able to get more insight into what's going on in these devices.

    I should also add that I used the command to get DMD training data and, given that the master is running reliably even after the DMD power rails collapse. I  got this result (my column labels are abbreviated, and this message system doe not like the tabs, but it's the data your command provides):

    DMD Training data:
    Pair Error pst High Slct Low Full Profile[50:0] (0=pass)
    A N Y 28 14 0 11111111111111111111111111100000000000000000000000000000
    B N Y 33 16 0 11111111111111111111110000000000000000000000000000000000
    C N Y 33 16 0 11111111111111111111110000000000000000000000000000000000
    D N Y 35 17 0 11111111111111111111000000000000000000000000000000000000
    E N Y 37 20 3 11111111111111111100000000000000000000000000000000000111
    F N Y 32 16 0 11111111111111111111111000000000000000000000000000000000
    G Y Y 42 23 4 11111111111110000000000000000000000000000000000000001111
    H N Y 41 20 0 11111111111111000000000000000000000000000000000000000000

    I presume this is satisfactory, bit it's only for the master lanes. Is there a way to ask the master to forward data (all of the stuff that can be accessed on the master, but this stuff in particular) from the slave? The programmer's guide lists commands involving mailboxes, external PAD devices, and internal registers (commands E5h through EDh) but does not explicitly indicate what these are for, provides few details and no examples. Do these commands provide what I need? Is there any better documentation for them?

    I accepted the friend request, but do not know how to send you a private message. I've been designing TI parts into things since the 1980s and have never needed to ask TI for help before, so I'm not familiar with this messaging system.

  • Hi Tim,

    I sent you a private message, you should receive an email notification or you can view the message through your E2E account. 

    Can you please send me the schematic of your custom projector through message if you don't want to share it on the public forum? This would help us better understand your design. 

    Thanks,

    Lori