• State Resolved
  • Locked Locked
  • Replies 24 replies
  • Answers 2 answers
  • Subscribers 28 subscribers
  • Views 2048 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

DLP6500FLQ: DLPC900 can not send ACK and it depends on pattern

Hiroyasu Tazawa1
Guru 12350 points
Part Number: DLP6500FLQ
Other Parts Discussed in Thread: DLPC900

Hi,

Let me talk about DLP6500.

We access DLPC900(DLP6500 EVM) via I2C using Pre-stored Pattern mode.

But DLPC900 can not send ACK. It depends on pattern.
It means it is success when pattern of horizon is projected continuously,
but DLPC900 can not send ACK when vertical of horizon is projected continuously.

We use these pattern.

veritical.zip

horizon.zip

We use same setting and only change pattern.
I do not know this reason.
Please let me know this reason, if you know.


Best Regards
Hiroyasu

  • 0
    TI__Mastermind 43135 points
    Hello Hiroyasu-san,

    First, what version of firmware are you using?

    I suspect this may be a result of the compression/decompression times. It may be that a newer firmware will help.

    The latest release version is 4.2.0.

    NOTE: Please be sure to have a backup of any previous version of firmware that you have before loading 4.2.0. Then try the latest release and report the results.

    Fizix
  • 0 in reply to Fizix
    Guru 12350 points
    HI, Fizix

    Thank you for your reply.
    My customer use version 4.2.0.

    Our setting is following:

    ===================
    (1) Pattern Display LUT Definition setting
    Write LUT data with write command 0xf8

    (2) Pattern Display LUT Configuration setting
    Writes the number of entries and the number of iterations with the write command 0xf5

    (3) Wait for a certain period of time

    (4) Pattern Display LUT Configuration confirmation
    The number of entries and the number of repetitions are read by the read command 0x75
    ===================

    I saw these results.

    Result 1:
    (3) waiting for a certain period is set to 500 ms or less, in response to the read command (4) in the I 2 C communication
    The behavior of DLPC is as follows.
    ① ACK does not come back
    ② The random value returns
    The random value is 6 entry, 6 times projection is specified, 32 times entry 0 times projection etc.

    Result 2:
    When the time standby of (3) is 600 ms, as the behavior of DLPC for the read command (4)
    ACK did not come back. There was no return of random values.

    Result 3:
    When waiting for a certain period of time in (3) is set as standby for 1500 ms, the behavior of DLPC with respect to the read command (4)
    ACK returned as.

    In the case of horizontal stripes, the read command of (4) is waited for a fixed time in (3) in any of the above cases
    ACK is back against.
    Behavior seems to be changing only by the difference of horizontal stripe pattern and vertical stripe pattern

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    TI__Mastermind 43135 points
    Hiroyasu-san,

    Thank you for your detailed reply. This will help us in troubleshooting this issue. We ask for your patience on this matter.

    Fizix
  • 0 in reply to Fizix
    Guru 12350 points
    Hi, Fizix

    Thank you for your reply,
    I wait for your answer.

    I can share more information, if you want.
    Thank you.

    Best Regards
    Hiroyasu
  • 0 in reply to Fizix
    Guru 12350 points
    Hi, Fizix

    Do you have any update ?

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    TI__Mastermind 43135 points
    Hello again Hiroyasu-san,

    We have not been able to recreate this behavior here. Could you please let us know how you are passing the commands.

    Are you using the GUI to send the commands or another program (i.e. customer's program using API calls)? If the GUI is being used, could you tell us what operating system is being used?

    Fizix
  • 0 in reply to Fizix
    Guru 12350 points

    Hi, Fizix

    How do you set ?
    We try to send data via I2C.
    Does it means you can not reproduce via I2C ?

    Best Regards
    Hiroyasu

  • 0 in reply to Fizix
    Guru 12350 points

    Hi, Fizix

    Could you reply ?

    Best regards
    Hiroyasu

  • 0 in reply to Hiroyasu Tazawa1
    TI__Mastermind 43135 points

    Hello Hiroyasu-san,

    We are using the DLPC900 Internal USB to I2C command set over DLP Composer Lite, but this may be different than what your customer is implementing.  

    We will have to change our setup here to try something different.  Please let us know what path they are sending the I2C commands.

    I am sorry for the delay.  

    Fizix

  • 0 in reply to Fizix
    Guru 12350 points
    Hi, Fizix

    >Please let us know what path they are sending the I2C commands.

    I do not understand this sentence.
    Customer use DLPC900 via I2C.

    and I have a question.
    File size of Vertical pattern and horizon pattern I sent are different.
    It means vertical file are about up to 52kB but horizon pattern is about 5kB.

    Are these big data size problem ?

    Best Regards
    Hiroyasu
  • 0 in reply to Fizix
    Guru 12350 points
    Hi,Fizix

    Could you reply ?

    This is I2C command.

    0xE9 :W: 0x01
    0xF8 :W: 0x00 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x00
    0xF8 :W: 0x01 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x40
    0xF8 :W: 0x02 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x80
    0xF8 :W: 0x03 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x00
    0xF8 :W: 0x04 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x40
    0xF8 :W: 0x05 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x80
    0xF8 :W: 0x06 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x00
    0xF8 :W: 0x07 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x40
    0xF8 :W: 0x08 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x80
    0xF8 :W: 0x09 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x00
    0xF8 :W: 0x0A 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x40
    0xF8 :W: 0x0B 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x80
    0xF8 :W: 0x0C 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x00
    0xF8 :W: 0x0D 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x40
    0xF8 :W: 0x0E 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x80
    0xF8 :W: 0x0F 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x00
    0xF8 :W: 0x10 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x40
    0xF8 :W: 0x11 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x80
    0xF5 :W: 0x12 0x00 0x00 0x00 0x00 0x00

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    Guru 12350 points
    Hi,

    Could you reply ?
    I need your help.

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    TI__Expert 4530 points
    Hi Hiroyasu,

    Please provide following info.

    1. Image that has pre stored patterns (Both images vertical and horizontal).
    2. More info on list of command sent and which one is nacked.

    Thanks,
    Tejender
  • 0 in reply to ykc
    Guru 12350 points

    Hi, Tejender

    Thank you for your reply.

    I re-posted stored images.
    Can you check these ?

    5557.horizon.zip

    6663.veritical.zip

    and I will check NACK point and let you know.

    Best Regards
    Hiroyasu

  • 0 in reply to Hiroyasu Tazawa1
    TI__Expert 4530 points

    Hi Hiroyasu,

    Sorry for confusion. I was asking for firmware images .img files (you are using prestored patterns ?).

    Thanks,

    Tejender

  • 0 in reply to ykc
    Guru 12350 points

    Hi, Tejender

    Sorry for delay.
    I attached 2 images.

    dlp6500_fw420.zip


    dlp6500_fw420_tate.img has issue image(verical images) and dlp6500_fw420_yoko.img does not have issue(horizon images).


    and I send command again.

    0xE9 :W: 0x01
    0x69 :R: read data
    0xF8 :W: 0x00 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x00
    0xF8 :W: 0x01 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x40
    0xF8 :W: 0x02 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x00 0x80
    0xF8 :W: 0x03 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x00
    0xF8 :W: 0x04 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x40
    0xF8 :W: 0x05 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x01 0x80
    0xF8 :W: 0x06 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x00
    0xF8 :W: 0x07 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x4
    0xF8 :W: 0x08 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x02 0x80
    0xF8 :W: 0x09 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x00
    0xF8 :W: 0x0A 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x40
    0xF8 :W: 0x0B 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x03 0x80
    0xF8 :W: 0x0C 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x00
    0xF8 :W: 0x0D 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x40
    0xF8 :W: 0x0E 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x04 0x80
    0xF8 :W: 0x0F 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x00
    0xF8 :W: 0x10 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x40
    0xF8 :W: 0x11 0x00 0x20 0xA1 0x07 0x7F 0x2C 0x01 0x00 0x00 0x05 0x80
    0xF5 :W: 0x12 0x00 0x00 0x00 0x00 0x00
    0x75 :R: read data

    In vertical case, it got stop when 0x75 command is sent.

    Best Regards
    Hiroyasu

  • 0 in reply to Hiroyasu Tazawa1
    TI__Expert 4530 points

    Hi Hiroyasu,

    Can you try with attached images. 

    image.zip

    Thanks,

    Teju

  • 0 in reply to ykc
    TI__Expert 4530 points

    Hi Hiroyasu,

    My board has gone bad. That's why I asked you to try the attached images in last post. My board is working now.

    I tried the sequence of i2c commands on image provided by you. I am not able to reproduce the problem.

    w means write 

    p means stop

    + means Ack

    1A is 7 bit i2c address

    e.g w 1A+ means 8 bit adrress byte.

    Note I don't send a stop between adrress write and read in case of register read operation.

    tate

    w 1A+ E9+ 01+ p
    w 1A+ 69+ r 1A+ 01+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F5+ 12+ 00+ 00+ 00+ 00+ 00+ p
    w 1A+ 75+ r 1A+ 12+ 00+ 00+ 00+ 00+ 00+ p

    yoko

    w 1A+ E9+ 01+ p
    w 1A+ 69+ r 1A+ 01+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F8+ 00+ 00+ 20+ A1+ 07+ 7F+ 2C+ 01+ 00+ 00+ 00+ 00+ p
    w 1A+ F5+ 12+ 00+ 00+ 00+ 00+ 00+ p
    w 1A+ 75+ r 1A+ 12+ 00+ 00+ 00+ 00+ 00+ p

    Please check the I2C master if its following proper protocol. 

  • 0 in reply to ykc
    TI__Expert 4530 points
    Never mind. I checked data I am sending was not same as yours. I am able to reproduce this with both tate and yoko. Both images show read timeout. I will check if there is something wrong in LUT definition commands.
  • 0 in reply to ykc
    TI__Expert 4530 points
    For now as a workaround I have figured out slight delay (try 1ms) between each command will avoid this issue. Meanwhile I will investigate rootcause of this issue.
  • 0 in reply to ykc
    TI__Expert 4530 points
    Delay can vary as per command. To be safe please use 10ms. In future FW release this will be fixed by providing a busy status GPIO that can be checked before starting a transfer.
  • 0 in reply to ykc
    Guru 12350 points
    Hi, Tenjender

    Thank you for your checking.
    I got it. If you find rootcaucse and next FW relrease, Please let me know.

    Best Regards
    Hiroyasu
  • 0 in reply to Hiroyasu Tazawa1
    TI__Expert 4530 points

    Hi Hiroyasu,

    Rootcause is if a command is being processed and new command arrives before previous command is over then new command can have unexpected results.

    Thanks,

    Teju

  • 0 in reply to ykc
    Guru 12350 points
    Hi, Tender

    O.K. Thank you for your support !

    Best Regards
    Hiroyasu