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.

System halt

Other Parts Discussed in Thread: DLPC200

Hello,

The DLPC200 often halt after DisplayPatternAutoStepForSinglePass command through SPI

Other commands works OK.

Please check your system if it is OK 

Regards.

  • Hi Youngjin,

    Can you please elaborate on "System Halts". Does it mean, it doesn't respond back to any commands after that? Something like is it hung and not responding to any commands?

    Regards,

    Sanjeev

  • Hi Sanjeev

    Yes, it doesn't respond back to any commands after that

  • Hello Sanjeev,

    The symptom is as belows.

    In DisplayPatternAutoStepForSinglePass, after sending command through SPI, DLPC sometimes echoed back different number and system stop.

    Please advise me

    Regards.

  • Hello Han,

    I'll have to debug the issue. 

    What command are you sending after calling DisplayPatternAutoStepForSinglePass API?

    Can your provide following information -

    1. Number of patterns? 

    2. Pattern Exposure Time?

    After sending DisplayPatternAutoStepForSinglePass command, can you send PWM_EnableSequence 0x0032 to enable the sequence. Let me know what happens...

    Regards,

    Sanjeev

  • Hello Sanjeev,

    I send the several commands, DisplayPatternAutoStepForSinglePass/DisplayPatternManualStep/DisplayPatternManualForceFirstPattern after calling DisplayPatternAutoStepForSinglePass.

    Number of pattern : 8

    Pattern Exposure Time : 8000us

    I tried sending PWMEnableSequence command as you mentioned but I'm not sure if it is working or not.

    Anyway the LED_RED_EN pin is always low after halt.

    I have one more question.

    After DisplayPatternAutoStepForSinglePass, DMD displays 8th pattern and next time it displays 1st pattern

    I like to display black image after sequence display

    Regards.

  • Hello Han,

    After DisplayPatternAutoStepForSinglePass, DMD displays 8th pattern and next time it displays 1st pattern 

    I think you are referring to momentarily displaying of 1st pattern after displaying 8th pattern, I have discussed this behavior in this thread http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/387/t/228263.aspx Let me know if you still have any other doubt.

    About another issue, no response after sending DisplayPatternAutoStepForSinglePass API, I will have to check here. Is it blocking you right now? Can you work with temporary work around (resetting the DLPC200)..

    Regards,

    Sanjeev


  • Hello Sanjeev,

    Yes....my customer is pushing me about this issue.

    Do you have temporary method for solving this problem ?

    All commands do not work after halt

    Regards.

     YJ Han

  • Hello YJ Han,

    First we will try to reproduce the problem you are facing. Then only we will be able to confirm what is going wrong. 

    Can you provide below info -

    1. Does your designed board has USB interface?

    2. What is the Firmware version you are using?

    The temporary workaround I think would be to reset the DLPC200 (by pulling device RESET pin or  I/O A14) of the controller.

    Regards,
    Sanjeev

     

  • Hello YJ Han,

    1. Yes, we have USB interface

    2. F/W version is as belows


    Regards.

  • Hello Han,

    I am pretty sure we have tested via USB that after sending the DisplayPatternAutoStepForSinglePass API, sending any other commands it works. Now, can you park/unpark the DMD via USB? Can you again call DisplayPatternAutoStepForSinglePass API via USB it should work..

    One more thing, can you send the the DLPC200 SPI echo response (MISO line) under the following scenario? 

    >> Send DisplayPatternAutoStepForSinglePass API command

    >> What is the echo bytes in the  MISO line?

    >> Send any other command.

    >> What is the echo bytes in the MISO line? Is it working at all or just physically stuck at one level.

    Regards,

    Sanjeev

    PS: We are working on reproducing the problem in our lab. 

  • Hello Snajeev,

    You are right.

    All commands including DisplayPatternAutoStepForSinglePass API through USB are working well.

    For the SPI, I checked sending bytes with echo bytes.

    When the system halt, the comparison result is different.

    And then I sent the other command, the echo bytes from DLPC200 are no problem.

    But the command does not work. 

    It is appeared when DisplayPatternAutoStepForSinglePass command is sending dozens of times via SPI.

    Regards.

  • Hello Han,

    Actually one of our colleague already tried reproducing the issue on the LightCommander controller board. The result is we cannot reproduce the issue that you are reporting. Everything is working fine.

    With this situation, now I think it will be difficult for us to debug further.

    As I requested please send the complete snapshot of byte transferred and echoed back on the SPI interface. Let me analyse it further.

    I expect following sequence of bytes 

    1. Command Bytes for DisplayPatternAutoStepForSinglePass with echo data

    2. Command response bytes for above command sent in #1

    3. Send any other command For example - Enable sequence, provide us the log of command and echo data

    4. Read the command response for above command sent in #3

    Regards,

    Sanjeev

     

  • Hello Sanjeev,

    When the system halt, the command stream is as follows.

    1. Command for DisplayPatternAutoStepForSinglePass : 0x02,0xAA,0x00,0x00,0x02,0x00,0x33,0x00,0x35,0x00

         echo data for DisplayPatternAutoStepForSinglePass : 0x00,0x02,0x00,0x00,0x00,0x02,0x00,0x33,0x00,0x35

                                                                                                    or 0x00,0x00,0x02,0x00,0x00,0x02,0x00,0x33,0x00,0x35

    2. Command Response bytes(read data) : 0x00,0x00,0x00,......0x00

    3. Send DisplayPatternManualStep : 0x02,0xAA,0x00,0x00,0x02,0x00,0x01,0x00,0x03,0x00

        echo data for DisplayPatternAutoStepForSinglePass : 0x00,0xAA,0x00,0x00,0x02,0x00,0x33,0x00,0x35

    4. Command Response bytes(read data) : 0x00,0x00,0x00,......0x00.

    Regards.

  • Hello Han,

    Clearly I there is a problem with your SPI master-slave setup on the board. 

    Not sure you have tried our suggestions in another discussion in this forum http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/387/t/256834.aspx

    Referring to your byte log

    1. Command for DisplayPatternAutoStepForSinglePass : 0x02,0xAA,0x00,0x00,0x02,0x00,0x33,0x00,0x35,0x00

         echo data for DisplayPatternAutoStepForSinglePass :

         0x00,0x02,0x00,0x00,0x00,0x02,0x00,0x33,0x00,0x35  (WRONG)

         or 0x00,0x00,0x02,0x00,0x00,0x02,0x00,0x33,0x00,0x35 (WRONG)

          0x00,0x02,0xAA,0x00,0x00,0x02,0x00,0x33,0x00,0x35 (EXPECTED)

    The DLPC200 SPI slave port is not able to sample incoming data properly. 

    This is the first step we should ensure its working properly. 

    Please re-look again your SPI master configuration. Perform steps suggested in this thread http://e2e.ti.com/support/dlp__mems_micro-electro-mechanical_systems/f/387/t/256834.aspx

    Regards,

    Sanjeev

  • Hello Sanjeev,

    For reference, I set the SPI master as belows

     Clock : 4MHz

     data transfer : MSB first

     data sampling : falling edge at trailing edge

    I know the byte log of DisplayPatternAutoStepForSinglePass in SPI is wrong.

    My question point is that only DisplayPatternAutoStepForSinglePass command do not transmit correctly.

    Other commands are no problem.

    DLPC200 return echo-back data to SPI master at sending commands correctly

    and send command response bytes exactly at reading command procedure.

    If my h/w do not sample data properly, why do not it work at only DisplayPatternAutoStepForSinglePass ?

    What is the difference in DisplayPatternAutoStepForSinglePass among other commands ?

    Regards.

  • Hello Sanjeev,

    More details, the SPI data in/out scenario is as follows.

    1. Send DisplayPatternAutoStepForSinglePass command via SPI.

         --> working well(all echo-back bytes are OK and command response data is correct)

     2. Send DisplayPatternAutoStepForSinglePass repeatly

        --> detect CMD_ERR_INVALID_CMD1 in reading command response, display is OK

             At this moment, CMD1 byte value is 0x00

    3. Send DisplayPatternAutoStepForSinglePass command and return wrong echo-back data from DLPC200.

       --> echo back bytes are 0x00,0x02,0x00,0x00,0x00,0x02,0x00,0x33,0x00,0x35, and display halt.

    4. Read command response

      --> the response bytes are all zero.

    5. After that, DLPC200 do not sample SPI data frequently and system stays halt.

    Regards.


  • Hello Han,

    It looks like DLPC200 entered into wrong state after Step2 above. It looks to me a timing issue.

    #2. Send DisplayPatternAutoStepForSinglePass repeatly - How you are sending the commands? Are you waiting for the response back from DLPC200 also add some delay before sending the next command?

    After sending the command, read the command response and then add a delay as follows -

    tPat = pattern exposure time (in us)

    nPat = number of patterns

    Total pattern display time T =  tPat*nPat (in us)

    Now add (T*2) us of delay and  then send the next command, let me know what happens. 

    One more thing,

    --> detect CMD_ERR_INVALID_CMD1 in reading command response, display is OK

    At this moment, CMD1 byte value is 0x00

    Whenever you see such errors in this case invalid CMD1 in the response it means it is not sampled the earlier received command packet properly, since the CMD1 in the previously sent was 0x02 but the DLPC200 sampled it as 0x00, in such cases you should read the complete response. Typical CMD1 to CMD4 kind of error condition the response size will be of 9 bytes. So you should send a total 9+1 = 10 dummy bytes to read the response completely.

    Then only you should proceed to next step.

    Regards,

    Sanjeev

  • Hello Sanjeev,

    It's solved to add enough delay-time as you mentioned.

    Thank you

    Regards.

  • Hello Han,

    This is good news. 

    Regards,

    Sanjeev