• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 31 subscribers
  • Views 3187 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DLPC350 FW3.0 I2C Validate and black pattern

Farzad H
Intellectual 270 points
Other Parts Discussed in Thread: DLPC350

Hallo I have 3 questions.

1: What does the 'Validate Sequence' Button in the Light Crafter exactly do?
I have a LightCrafter 4500 with both USB and I2C attached to a computer.
I want to test Pattern mode with a video source initialized via I2C, which was buggy until FW 3.0.0.
To initialise I send the following sequence:

// write
E9 01
E5 00
EF 00
F5 00 01 00 00
F0 00
E6 10 27 00 00 10 27 00 00
F7 02
F6 00
F8 01 71 06
F7 00
// read
7D
20
21
22
// write
E5 02


When I do this the pattern does not start. Validation return 0 like it should.
When I use the 'Validate Sequence' button instead of the I2C reads and then start the pattern with the I2C E5 02 the pattern works. Where is my error or do the I2C commands still not work?


2. There seems to be always a little bit light in the parts of an image that is supposed to be black, even in pattern mode. Is it possible to not have that?

3. The other way around, can I leave away the black vector so that the patterns can change from one to the other without any 'blackouts' between them?

  • 0
    TI__Mastermind 30875 points
    #1. After issuing Validate I2C command are you not allowing any delay? Add 100ms delay and then read the validation status.

    #2. It may be stray light coming out of the light engine. This off-state light that is appearing on the projected image. You have to rework on the optical system for having better contrast. Talk to our Design House partners they may be able to help you designing system to avoid the off-state light to achieve better contrast.

    #3. Yes, if you don't add a black vector then you will not have gap b/w the patterns. Now we recommend having black vector for the last pattern this will ensure that the last pattern is exposed for the duration we requested else it will continue to show the last bit-plane of the last pattern.

    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Intellectual 270 points

    Hallo Sanjeev,
    thanks for your answers!

    #1. For the bug hunt I send the commands by hand via a PC-I2C Adapter, so there is a 100 ms delay guaranteed.
    I analysed what the LightCrafter GUI sends and changed my I2C commands to be exactly the I2C counterparts to the USB commands, but still no success. The Hardware status Register shows a 0x41: init success and sequencer abort bits. That error disappears in the GUI.
    My initialsation over I2C works when I use the validation and play button of the GUI. Any Ideas? Could you verify that these cmds are okay?

    E9 01 // Pattern Mode
EF 00 // Pattern from Stream
F5 00 01 00 00 // Pattern count
29 10 27 00 00 // Flash Start Address (just because the GUI does it too at this time, mostlikely not important)
F0 00 // VSYNC as trigger
//E6 10 27 00 00 10 27 00 00 // this time without the exposure time because the GUI doesn't do it either
F7 02 // open LUT
F6 00 // set Index
F8 01 71 06 // send Pattern, trigger external, white LED, black vector buffer swap
F7 00 // close LUT
F7 01 // open LUT
F6 00 // set Index
F8 00 // set image index
F7 00 // close LUT
// Read
7D // validation
//write
E5 02 // start pattern

    #2. First I thought that too. But in our laser device when I switch from Video mode to pattern mode (just after the Display Mode command, not a complete initialisation) the light in the dark placed is away. This of course is no valid operation mode, the mirrors can't be changed, we just happed to notice that because problem #1. We use 24 bit video, with a black and white image (in theory we could show colors but the content is only black and white).

  • 0 in reply to Farzad H
    TI__Mastermind 30875 points
    #1. When you are sending the commands is the Video SYNCs already present? After sending 0x7D are you reading back the validation status to make sure no errors reported? Note E5 0x2 (start pattern) will be executed successfully iff there is video signal present; if you send this command without video Start Pattern itself will not happen, you can read and check if register 0x65 is 0x02 after E2 02 command is sent. So ensure the video is active.

    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Intellectual 270 points

    The SYNCs should be there as I can see the video image of the LightCrafter before I send the above I2C-Commands. Also in our product is the video signal constantly generated.

    I am reading register 0x7D and the result indicates no error.

    Regsiter 0x65 does not take the value 2 it stays 0.

    As I understand you, my command sequence is correct and supposed to work?
    Can anything else explain the difference between USB and I2C commands?
    I want to add that I am reading with a write and a read command with regular start and stop conditions and without a restart condition just as the datasheet indicates.

  • 0 in reply to Farzad H
    Intellectual 270 points

    Has anyone got the pattern mode running using I2C for the settings?

  • 0 in reply to Farzad H
    TI__Mastermind 30875 points
    Hi Farzad,
    Sorry, I overlooked your I2C command sequence, actually your command sequence has a mistake i.e., I2C 0x7D won't start the validation task, it is treated as the [Read] Validation status. Remember you must do BIT7|0x7D (Write command) to invoke validation process.

    So change I2C sequence to for validation to
    //Invoke validation
    0xFD 0x00
    //Delay 100ms
    //Read the validation status
    0x7D in a loop with 100ms delay for each read until your see the read back byte has BIT7 cleared.

    This should fix the issue.

    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Prodigy 10 points
    I've been trying to send a pattern LUT to the LC4500 over I2C and have not had any luck. I've used the USB interface for this in the past and it has worked fine. After struggling with this for a week, I found in the forum that this was a bug in firmware 2.0.0 and reportedly fixed in firmware 3.0.0. So I upgraded to firmware 3.0.0 and it still doesn't work. I have checked my code many times, and what I've found is that every other command over I2C works fine, as well as my code for sending a pattern over USB. It seems like the "Pattern Display Variable Exposure LUT Data" command over I2C simply doesn't write its data to the correct place. Then in validation, random errors will occur due to the LUT memory having never been written.

    I have a hunch that this issue simply wasn't fixed in v3.0.0. When you tested I2C, is it possible that you were fooled into thinking it worked by first loading a pattern over USB? In this case, it would appear to work because the pattern has already been written there in memory. Have you tested an I2C pattern from a fresh boot of the LC4500 (with no help from USB)? Have you tested uploading a different pattern over I2C?

    Thanks.

    -Ken S.
  • 0 in reply to Kenneth Silverman
    TI__Mastermind 30875 points
    Hello Ken,

    This is bug on v3.0 firmware.

    As it stands the legacy Pattern Display LUT (I2C:0x78) works fine on v3.0 but new the Pattern Display Variable Exposure LUT Data (0x5D) doesn't.

    At present, we know the root cause; most probably we would like to wait for some more time to see if any other issues come up so that we can release it as one update.

    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Prodigy 100 points

    Hello Sanjeev,

    I did not see a reply from Farzad to your post of Nov 15, but I am having the same problem as he was, even after implementing the validation method from your Nov 15 post.

    Everything else works to set up pattern sequence mode from 912x1140 video input via I2C commands, but so far only a validation issued from the GUI is enough to let it actually start running.  I can even issue the run command successfully via I2C, but only after performing the validation from the GUI.  I have tried repeatedly to perform the validation via I2C according to the method from your post of Nov 15, and while it returns no error, it never has the effect that validation via the GUI over USB has.

    I too am using the 3.0 firmware, and I would like ask again the questions that Farzad posed:

    When you tested I2C, is it possible that you were fooled into thinking it worked by first loading a pattern over USB? In this case, it would appear to work because the pattern has already been written there in memory. Have you tested an I2C pattern from a fresh boot of the LC4500 (with no help from USB)? Have you tested uploading a different pattern over I2C?

    Richard

  • 0 in reply to Richard Greene
    TI__Mastermind 30875 points

    Hi Richard,

    After closing the mailbox add 100ms delay. Then issue the Validation Command - (0x7D | 0x80); after this add 100ms delay. Now check if your are able to run the configuration.

    Regards,

    Sanjeev

  • 0 in reply to Sanjeev
    Prodigy 100 points

    Sanjeev,

    Thanks!  I already had that delay, but I'd neglected to set the high bit when writing to just hat one (validation) register:(  My bad.  Now it is working with the 3.0 firmware, successfully putting the projector into pattern mode even after a cold start into video mode.

    One more question: we have projectors in the field running the 1.x firmware, that would be difficult to upgrade to 3.0.  Should the same code for going into pattern mode work with those, as long we reverse the byte order (MSB instead of LSB first) for the exposure time & frame period register (0x66 | 0x80)?  Does the byte order also need to be reversed (for firmware 1.x) for the other multi-byte registers used to set up pattern mode: LUT control (0x75 | 0x80) & LUT data (0x78 | 0x80) ?

    Richard

  • 0 in reply to Richard Greene
    TI__Mastermind 30875 points
    Hi Richard,

    You can look at the DLPC350 firmware release notes for v2.0 and v3.0 certainly there have been improvements and bug fixes.

    Now back to your question, b/w 1.x and v2.0 your front end can send commands as it is there is no change in the MSB LSB ordering.

    in v3.0 (refer to the readme) we have strictly maintained LSB to MSB order matching to the USB command interface specification. So if you are using v3.0 f/w update, then your front-end need to be update to follow the LSB to MSB ordering.

    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Prodigy 100 points

    Sanjeev,

    Thanks again.  From Readme with the 3.0 firmware, it looks like of the pattern mode registers I'm using, only the byte ordering for the Exposure Time and Frame Period register (0x66 | 0x80) was different in the earlier firmware versions.

    Richard

  • 0 in reply to Sanjeev
    Intellectual 710 points
    Hi, Sanjeev-san

    Please tell me.
    Q1: Is there I2C command that need to wait for 100ms in the other?(except mail-box closed and varidate(0x7D|0x80)
    Q2: Why it is necessary to wait for 100ms? If possible I want to short.

    Regards,
    Masa
  • 0 in reply to Masayuki Iwata
    TI__Mastermind 30875 points
    Q1: No other with respect to the pattern sequence configuration.
    Q2: The delay is needed for the DLPC350 process the command.
    Regards,
    Sanjeev
  • 0 in reply to Sanjeev
    Intellectual 710 points

    Hi, Sanjeev-san

    Thank you for answer.

    I understood.

     

    Regards,

    Masa