SN65DSI84: I2C NACKs in chip setup / chip mem map readback

Hi Sebastian,

I am looking into this issue, I will get back to you tomorrow.

Best,

Cameron

Adding new info:

We also verify that, when setting up the chip through the I2C write transactions, even when they happen during LP11 of the DSI, we get NACKs for the first byte (I,e, chip not ACKing its I2C address). In the pic, LA with EN in the last channel, then I2C bus with the write transactions. 4 NACKs of 10 transactions.

 

Thanks Cameron, please let us know as soon as you have something (as we are with pressure).

Hi Sebastian,

I have a few questions about the set up you are using:

1. Is this a custom board or an EVM?
2. What is the supply voltage you are using?
3. What pull up resistors are you using on the SCL and SDA lines?
4. What speed is the I2C you are attempting to use?
5. Could you send me the *.sal file with the I2C transactions you captured from the Logic 2 program?

Best,

Cameron

Hi Cameron,

1. Custom board. Schematics for the bridge, here:

2. This subsystem is powered by a 1v8 LDO. It's an output from RK806-1 PMIC, and the PMIC is mounted in the CM5 (in Radxa's computer module). 
3. 4k7 pull ups to the same 1V8. Today I'll test with stronger 2k2 but I traced with scope and, whilst there is RC, it looks fine. This is the only component in this I2C bus
4. 100kbps
5. I'll post today here the SAL for that one, and others (burst reading with i2cdump, etc)

Thanks!
Question: Is it expected to have I2C Addr calls unanswered by the chip?

Hi Sebastian,

Thanks for the extra info. 

Sebastian de Leon said:

Question: Is it expected to have I2C Addr calls unanswered by the chip?

No, it should follow the standard I2C protocol.

Sebastian de Leon said:

2. This subsystem is powered by a 1v8 LDO. It's an output from RK806-1 PMIC, and the PMIC is mounted in the CM5 (in Radxa's computer module). 
3. 4k7 pull ups to the same 1V8. Today I'll test with stronger 2k2 but I traced with scope and, whilst there is RC, it looks fine. This is the only component in this I2C bus
4. 100kbps
5. I'll post today here the SAL for that one, and others (burst reading with i2cdump, etc)

This all looks okay, I'll take a look at the SAL file once it's ready. 

One other question I have for you, what address are you using when you try to set up a read? I see in your schematic that you are grounding the ADDR pin, so this sets the device in the mode of having an 8-bit I2C address of 0x58 for writes and 0x59 for reads. Are you changing the address between your reads and writes?

Best,

Cameron

Hi Cameron,

Yes we use 0x58 / 0x59. Just to clarify, it's not that we can't do reads and writes at all, we have issues in around 0.5% of the transactions (but most of them are ok, both read and write)

Hi Sebastian,

Oh, my understanding was it was a large percentage of the transactions that were getting NAK'ed. Is this happening only on one board, or has this been reproduced on multiple boards?

Best,

Cameron

Hi Cameron, 

This happens in multiple boards.

In the sequence attached, there are 10 reinitializations of the DSI84 chip

There is a total of 872 I2C transactions / Host calling DSI84 in the bus

Of those 872 address calls, there are 9 unresponded calls (I.e Host doesn't ack the I2C call)

* Signal integrity is fine
* For most of this, there is good spacing between the previous transaction and the nack'd transaction
* There is only one device in the bus
* It happens for different registers, in different parts of the initialization.

Originally our concern was that the mainline Linux driver was not doing retransmits, so we were having in the fields blanks screens (that couldn't initialize)
We fix the driver and now every i2c setting to the DSI84 has a readback to verify, and also retransmits if NACK'd

Our concern is still that 1 out of 100 transactions NACK'd in an I2C bus is a big unjustified number. We think there are machines in the fields were it might even get worst. So we need to understand why this is happening.

Please find attached the SAL for the 10 reinitializations.
Also the csv of that SAL capture

The NACKs are in rows of CSV / times in SAL:
Row 633: 12.87952 s
Row 665: 12.88811 s
Row 2012: 27.08261 s
Row 2066: 27.09671 s
Row 2105: 27.10599 s
Row 2283: 27.15259 s
Row 2981: 43.92724 s
Row 3383: 50.61638 s
Row 3423: 50.63 s

Thanks, and have a wonderful weekend.

Update: The system doesn't allow me to upload the SAL file, can I have an email and I send it to you?

10_DSI84_reinits.csv

Hi Sebastian, 

My email is c-hoholik-carlson@ti.com, you can email me the .sal file there. Maybe putting it in a zip file will allow you to upload? Not totally, sure. 

Thanks for the additional info, that is all definitely a valid concern. Once I get the captures, I'll review them and work to determine what is going on. 

Best,

Cameron

Hi Sebastian,

I got your email with the sal file. For next steps, could we take a look at the rise/fall times and setup/hold times of your I2C bus? I want to eliminate the case where the I2C configuration is borderline meeting the datasheet requirements, causing the infrequent failed transactions.

Best,

Cameron

Hi Cameron, 

Thanks for the follow up!

Adding 2 scope captures below, that will answer those questions. The bus is operating at 100kbps, There is a Tr of 1us, and a negligible Tf.

Data transitions are happening at half way of the clk in 0 state, allowing worst case T_setup of 2us. T_hold is > 4us

I also did some tests with 2k2 pull ups (I have 4k7 in the board's BOM) and, whilst should give me better Tr and T_setup because of improved T_r (I didn't measure with scope for that case), I get similar statistics of NACKs (i.e 1 every 100 or 200 transactions)

The very short pulses in SDA in the first trace is the TI chip pulling down the line to ACK the transaction (If the ACK is there, as in, 99%-99.5% of the cases, it's ACKed very fast.

Thanks!

Hi Sebastian,

Thanks for the testing and scope shot, this is helpful. I would be curious to see the behavior when the rise time is lowered some, would you mind using the scope with the lower pullup resistor values?. According to the I2C spec, the maximum rise time is 1000ns or 1us for running the bus at 100kHz. So ideally, lowering the resistance and rise time would ensure that it is consistently below the max and improve the NACK frequency. 

Additionally, is there a separate I2C controller that you have access to? We typically use an Aardvark or USB2ANY with our EVMs, I would like to try a different controller to ensure the issue isn't related to the SoC or its I2C driver. 

Best,

Cameron

Hi Cameron,

Thanks again for your response. I'll trace that. Also I'll get a different i2c master to drive the chip. On this note, I build a separate board for the DSI84 (like an Eval, as the one TI has is using the DSI83). I'll get traces of that board as well, with our current SOC, and with others.

Let's get all the combinations. Will take me a bit but I'll update asap.

Thanks

Hi Sebastian,

That sounds good, let me know if you have any questions in the meantime.

Best,

Cameron