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.

DLPC3438: Can a I2C command processing error occur when a read request takes too long to complete?

Part Number: DLPC3438

Hi,

we are experiencing rare communication errors with our DLPCs. After they initialized we tell the DLPC to switch the LEDs on. Sometimes it can happen that checking the Communication Status afterwards shows a "Command Processing Error" (0x04) for Op-Code "0x00".

We saw that during the "read request" for checking the Communication Status there can be a pause of up to 40 ms between the "0xd3" byte (Op-Code for Communication Status) and the "0x02" byte (read parameter: I2C).

My questions are now the following:

1. Can a delay of 40 ms between the two bytes of a read request lead to the DLPC aborting this request? (Because a timeout happens while waiting for th read parameter)

2. What does Op-Code 0x00 actually mean, as it does not refer to an existing Op-Code?

For better clarification of the situation I added screenshots of the communication.

I have not found any answers to these questions in the respective datasheets and manuals so any hint is appreciated.

Kind regards,

Benedikt

  • Benedikt,

    Welcome to the E2E forums and thanks for your interest in our DLP technology.

    A couple questions from me to help set context:

    > What kind of source are you using to the drive the I2C bus? Are you using an EVM over Cypress USB? Is this a custom board with your own I2C frontend? etc.

    > When you encounter an I2C error, are you seeing any fail behavior on the controller side (such as the LED state not switching) or are we specifically seeing error bits on the communication register and no other symptoms?

    > What DLPC firmware are you using?

    Regards,

    Philippe

  • Hi Philippe,

    our source is a Raspberry Pi 3 Compute Module with the bit-banging driver i2c-gpio. Everything is integrated on a custom board made by us.

    I cannot say for sure, yet, if the LEDs don't switch on because we had implemented a retry mechanism in our firmware so that after a failed communication the transaction is repeated. Most of the time it is successful then but in even rarer cases we see the transaction failing three times in a row.

    We're using a customised 7.3.3 firmware (which was kindly tailored for us by your colleague Austin Snyder).

    Best regards,

    Benedikt

  • Hello Benedikt,

    To address your questions:

    1. This delay is likely the processing of the controller to return the command. Does this timing change if the 0x00 opcode does not precede?

    2. The 0x00 is not an Op-Code that is recognized by the embedded software. This may well be the reason you are receiving the Command Processing error. Do you experience communication errors with any other command that is listed on the Software Programmer's Guide?

    Regards,

    Austin

  • Hey Austin,

    I think my screenshots were a bit misleading. The 0x00 in the first screenshot is the answer of the DLPC to a request of the Communication Status which happened before the first longer period of inactivity observable in the CLK signal (yellow). Everything you see on the screenshots is communication with the DLPC. At no time are we issuing a request with an op-code 0x00.

    Also I'm not sure that the long delay is the DLPC needing its time because when I had a closer look at the signal it is visible when the DLPC holds the clock and when it releases it (visible as a slightly lower signal voltage in the CLK signal for a short time). This is also visible after the 0xd3 Byte in the first screenshot, right before the long pause. This long delay happens only once in ca. 1000 boot cycles and is most likely caused by the I2C driver of the Raspi.

    We are checking the Communication Status after every single transaction. So most of the time the answer by the DLPC is 0x00 0x00 (no error). Only after the command to switch on the LEDs when we try to read the status again sometimes there is this long break between the op-code and the read parameter for the Communication Status read request and that is when we get 0x04 0x00 as an answer. And I don't know why and what it means.

    I hope I could clear up things a bit? I added some comments to my screenshots which may also help.

    Kind regards,

    Benedikt

  • Benedikt,

    I believe I understand the issue. We will certainly need some time to try to reproduce the behavior before we can give feeback. Expect a response from us by end of next week.

    Regards,

    Philippe

  • Hi,

    I dug a little deeper and found that the SMBus specification defines a timeout of 35 ms for devices that detect tha a clock signal is held low for too long. Might this be the case for the DLPC that it implements this timeout? The DLPC datasheet only states that it implements I2C according to the Philips specification and these specs mention SMBus and that they are to some extent compliant but that the latter for instance adds this timeout constraint.

  • Benedikt,

    Thanks for the feedback; this is certainly helpful or other members on the forum. If we find any new information to share beyond this we will post back here.

    Regards,

    Philippe

  • On a closer look I became convinced that the time the clock is held low is most probably the DLPC using clock stretching. This is visible in the attached screenshot with three different voltage levels of the CLK line.

    So from the controller side everything looks fine. That still leaves the question, what the strange looking answer of the Communication Status means

  • In the meantime I tested NOT checking the Communication Status but instead re-reading the registers that we wrote values to. So for instance after we enable the LEDs we want to check whether the change was successful so we read the status of the LED enable register.

    Since in the beginning we had problems with our controller not handling clock stretching correctly we could run into problems where we read wrong data. So we employed a scheme where we would try multiple reads and compare the results. This was still active when I now checked the LED enable status and on successive reads I got three answers, where the first and third answer indicated that the status was "enabled" but the second answer indicated "disabled". How can this be the case?

    Best regards,

    Benedikt

  • Benedikt,

    Thanks for the feedback. Some followup questions from me 

    > Do you have any other I2C devices on the bus? If so, are there any that are attempting to communicate with the DLP controller? 

    > In terms of the readback information from the I2C (such as the LED register example above) do you see the same problem by adding artificial delays of some significant margin (say, 1 second) between reads? Or does the problem only occur when rapid-fire I2C reads are sent out one after the other? 

    > What speed is your I2C bus operating at in kHz?

    Regards,
    Philippe

  • Hi Philippe,

    Yes there are other devices on the bus. None of them does use clock stretching though and none of them does communicate with the DLPC other than the single master.

    I did not try to add an artificial delay, yet. The bus is operating at ca. 100 kHz. (In the screenshots its actually less, around 85 kHz but the errors occur in both cases).

    Best regards,

    Benedikt

  • Benedikt,

    Thanks for elaborating. Please try performing an artificial spinning delay to characterize the problem (perhaps the problem occurs when commands are being sent a particular rate). 100 kHz should be OK for operating speed.

    Regards,

    Philippe

  • Hi,

    in the meantime I was able to test the communication with a significant delay between each I2C transaction with the DLPC of 0.5 seconds. I could only check for the Communication Status error mentioned in my initial post and this did not occur again, yet. As for the differing consecutive readings I had no means to automate this test.

    I hope this helps you with the analysis of the problems.

    Best regards,

    Benedikt

  • Benedikt,

    Thanks for your feedback. Have you tried using an SoC such as a Raspberry Pi to perform the commands? You can write a script to automate the Pi in this manner.

    Regards,

    Philippe

  • Hi Philippe,

    yes I tried that but could only perform single byte reads with the Linux i2ctools instead of the block reads we do in our Firmware . I did not experience any problems with wrong readings with this method.

    So what shall we make of all this? That it is advisable to wait for a certain amount of time between each transaction with the DLPC? If yes, for how long?

    My solution currently is not to check the communication status and not to re-read the register after writing to them because it seems I cannot trust the results unless I wait for an unknown amount of time between each transaction and then who knows. I was hoping you could help me understand the answers I got from the chip.

    Best regards,

    Benedikt

  • Hi Benedikt,

    Please allow us until next week to look into this further. Philippe has been working on a demanding project not related to E2E, and has very limited bandwidth

    As you probably already know this issue you are seeing is very tricky to debug. Thank you for your continued patience,

    Regards,

    Arthur