DS90UR910QEVM: DS90UR910QEVM - No I2C communication

I will get back to you by end of the week or early next week. 

Hello Daehyun Kim

  1. Can you let us know what board you are using for DS90UR910? I am assuming you are using our EVM. Is this correct?

  2. What is JP3.1,2,3 ad 4 connected to?

  3. What is your VDDIO voltage and what is your i2c voltage?

  4. Are you using our ALP software to read?

  5. What state do you see on I2c pins when you don't connect any i2c master?

Thanks

Vijay

1. Correct.

2. JP3.1 3.3V, 2. SCL, 3. SDA, 4. GND to STM MCUs

3. 3.3v and 3.3v.

4. No, but this is to be used with Android Application and standard i2c com. is expected to work. We tried in Android Dev board, Linux Dev board(including Jetson), Arduino... all their i2c works fine except with DS90UR910QEVM

5. both constant high

Hello Daehyun Kim

  Is it possible to use ALP (and USB2ANY) just as a debug step? If not , suggest the following steps:

1. i2c slave address is determined by what ID[0] and ID[1] pins are connected to. Please ensure these addresses are not used by any other slave devices

2. Please ensure that the SDA and SCL are pulled by a pullup on the EVM and there is no direct short

3. There is a chance that ID[0] and [1] may have been left floating

4. There is a small chance that maybe the EVM is bad or has a short or some other electrical damage. That's why I'd recommend you use ALP and USB2ANY as a debug step

Thanks

Vijay

We don't have USB2ANY for now. 

1. This is exactly why we tested something as simple as Arduino - 1 simple master and 1 simple slave - No communication. 

2. There is no short observed. 

3.  Checked R28, R29 are nominal.

We got this on 12th, August this year from Ti.shop and spent 2 weeks trying programing. I think it's the small chance happened.

Any other suggestion?

Hi

 Can you let us know what ID[0] and ID[1] pins are connected to? Also please send us the i2c address you were trying to program to ..(this is based on ID[0] and ID[1] pins). In parallel we will test a generic 910 EVM to see if we see any similar issues. If not, we may send you another EVM that is tested . Other than the addressing being wrong or some sort of pin damage that may have happened, we cannot think of why i2c would not work. Can you also please ensure that the clock and data are not swapped etc (when you are driving it from the master..,simple checks but we do get questions where lines are swapped

Thanks

Vijay

On the EVM, ID[0] and ID[1] are not pins, but they are dip switches...

mostly tried (0x78) which is ID[0] L, ID(0) L. Also tried, all the other combinations, and ran i2c detect many times see if there is any i2c ACK from the slave but none.  

If I2C is anyway alive, there has to be any sign of ACK or NACK to that address, but simply none. 

SCL and SDA aren't swapped for sure. EVM isn't the only slave in our various i2c platforms. 

No visible pin damage in the naked eye. 

Hi

  Here are couple of more things to check. Please look at your master to see if there is already a pullup resistor. If there is , then connecting to our EVM means, you may be doubling up on the pullup value. What is the drive strength of the i2c master pull down? If you are doubling up on the pullup resistor value, and if the drive strength of the master you are using is not enough, then you may not be able to pull the bus low. 

Thanks

Vijay

There are no redundant pull-ups. 3mA. There is no slave other than the EVM. 

Other than this EVM, i2c slaves are work fine with the master. i.e. capacitative touchpad. 

Hi

   Does the i2c master have a pullup? So we are talking about a pullup on themaster appearing in parallel with the pullup on the EVM reducing the overall pullup value and basically holding the i2c bus at high. Other slaves you ave tried the master with, may not ave had any pullups. If this is the case you may want to remove the pullups on EVM or atleast triple the pullup value

Thanks

Vijay

As I said, no pull-ups in any masters I tried.

Most of the commercially available touchpads which is an i2c slave have the pull-ups near the flex cable of touch controller.

If there has been doubled like you are wondering, I have seen clearly there is fault in the master side. 

I do understand with given information and steps to ensure no further mistake, it takes time and patience for troubleshooting,

but for the whole time I've been telling only the EVM is trouble.

To be clear, no redundant pull-ups. The masters are not prototypes but commercially available SBCs that do requires pull-ups on the slave side. 

I came to this forum not because I have a question, but TI store support sent me here as a warranty replacement step.

I really would like to try another EVM. 

Hello Daehyun

        Let me summarize what had been discussed so far so we have common understanding and maybe try one last experiment before we try another EVM and find out it behaves the same way:

1. Your I2C master does NOT have any external pullups. I understand this. If you identify the IC that is used as the I2C master, we can check the Datasheet of that IC and see if the IC has an internal pullup resistor

2. There are no other i2c slaves on the bus other than 910 EVM. This is understood

3. If you use other commercially available i2c slaves, you do not see any issue. I also understand this. The issue you are seeing happens ONLY with 910 EVM and I also understand this

4. I think the reason why the issue ONLY happens with 910 EVM is because of the presence of the 4.7K resistors on the pins 14 and 15 , SCL and SDA on Header 4. I believe 4.7K resistor on our EVM is too small a value and is driven and held strongly closer to 3.3V and the drive current of the i2c master you are using may not be strong enough to pull the bus down. We have tested our EVMs with for eg, Aardvark i2c master (TP240141, as given in EVM user guide). The i2c pull down current on this master , per Aardvark's datasheet is 10mA which means it is strong enough to pull the i2c bus down. So if you are using an i2c master that has a max pull down current of only 2.5mA, then it will not be able to drive the SDA and SCK pins low and this may be something you are seeing only with our EVM because the other slaves you have tried may not have this small a pull up resistor to the 3.3V. So I'd like to suggest that you replace the 4.7K resistors on our EVM with 12K or so resistors and see if this fixes the issue

Thanks

Vijay

Replaced the master with the spec note saying 'General I2C 1 Clock/Data. 4.7kΩ pull-up to 3.3V on the module.'(Android SBC).

The call returned 'i2c_transfer -6, said NACK error', that is, no response from the EVM.

kernel/arch/arm64/boot/dts/rockchip/rk3399-firefly-mini-edp.dts
&i2c4 {
    status = "okay";
    _UR910: _UR910@78 {
              compatible = "_UR910";
              reg = <0x78>;
           };  
};

Since the address is correct (0x78), we can rule out the address issue.

Thus, it seems the EVM's i2c is not in working condition. 

follow up, please!

Hello Daehyun

 I am not sure I understood what you mentioned above. Here is what we did, we took a 910 EVM that we have and used our own USB2ANY. The address that came up by default is 0x60 when read from the part but in our ALP platform we used 0x78 to access the part. So appreciate if you can do 2 things: one is try 0x60 as the address first and see if the 910 responds.If it does, then the issue is fixed. If not,  please send me a scope shot of SDA (i2c data bus) showing that the Master was indeed able to pull the bus low. If you read a NACK but did not see the Master pulling the bus low, then it means the drive current may be too low

So the following shows SDA voltage value that it's indeed pulled down.

and i2cdetect found no slave on i2c1

Follow up, please.

It's approaching already a month, and I think it might be better to buy another and return the previous one. 

Well, we came this far and I expect yay or nay for a replacement to try out. 

It's disappointing that no one is replying now.  

Hello

  We had to find out if it can be replaced. Based on TI policies, there is no replacement for the EVM . You will need to order a new EVM. Also looking at the scope capture, the SDA waveform is always constant level. If SDA is being pulled low(or High), you will see transitions on SDA like what you see on SCLK. Since that is not happening, ie , you are not seeing a transition on SDA and if SDA is always low, then you have to reduce the pullup resistor value on SDA (reduce it to 750 ohms or 1K)

Thanks

Vijay

This is unacceptable.

Ti store sent me here to get it checked and get a replacement. 

I purchased this kit from TI shop on 9th August, and ever since then this did not work at all, in terms of i2c communication. 

Then TI shop agent closed my case as it's E2E support that is responsible for this kind of customer service. 

And you and me wasted nearly a month here going back and force. But yet again, with all due respect, you cannot explain why clearly nor diagnoise the problem.

From then and now you keep just talking pull up registers valute to be altered but this is what TI designed.

In most cases, even if EVM are provided AS-IS, customer expects EVM to work as data sheet provided. 

With given conditions provided, EVM is behaving abnormally.

This is violation of contract. I expected this to work as-is, but clearly it didn't work, and you cannot explain why it is not working

as is. Even if I made the alterlation can you guarantee that it would work? This EVM act weird! now SDA stuck low, but 

at the other time it was all high without any pull-ups altered. If at least once it showed a proper i2c signaling I would accept any fault on my side, but it wasn't. 

You are talking about a policy but, what is it? Tell me. 

In that policy exactly where TI would not service their customer and their product like this? as far as I remember that I am explained by a TI store support

, indeed, TI do not guarantees EVM like other product, but within 15 days, with given condition that if it is found defective, TI may provide a replacement. 

I wasted times here at this forum several days and I am afraid all of this does not seem a proper support but playing of words according to my description provided. 

I will file a chargeback request to my credit card company.

Even I myself run a small business, but I don't serve like this.

It's my first time dealing with TI first time, but this is unacceptable and unimaginable. NXP is much better than this. 

TOS says 

8.1 Subject to Sections 8.2 through 8.4, 9 and 11 below, TI warrants to Buyer that each Product conforms to TI’s published Specifications for such Product.

All your suggestion was to do something else than what is published specification.

This EVM should have worked as published description says, but it didn't.  

I don't see anywhere in the terms and conditions of sale saying that TI reserves rights to refuse any claim because it's an EVM.

I know it's not refundable, and I am not asking a refund, but a replacement.

Your reasoning is not justified in any manner. 

I think, what we are not able to establish is whether the EVM has an issue yet. Having said that, I do understand your frustration, let me check back with our TI-legal/EVM team and what is OK . If we decide to send a tested 910 EVM, can you let us know what address it would be sent to?

Thanks

Vijay

Thanks for understanding.

I know you are here to help, but this EVM is a source of frustration for us several days. We are designing a new platform based on Android that does not rely on conventional designs and DS90UR910Q looked promising. If any other i2c slaves are not working with our masters, we'd accept it, but only this particular EVM is troubling. If a replacement becomes available, have it sent to 

RSNAV.com (Attn: Daniel KIM)

10122 St-Vincent, 

Mirabel, Qc

Canada

J7N-2Y2

1-802-552-3053

Hi

    I will be sending you the details about the process today. Please note  that you may have to return the EVM that you have . I will forward you the details later today

Thanks

Vijay

Can you send this info:

How did you purchase this EVM? Directly through the store order or through Digi-Key, Mouser or Kimball? They will need to contact the rep on that end to return the material and from there I will receive an RMA request to process.

Thanks

Vijay

It's direct order on TI store order no. T00490564

Hello

The process is to get a request (case) created at www.ti.com/csc. The customer support center will help with processing a replacement. Please do say that I2C is not working. Once you get a new EVM, if you are still seeing issues, you may need to start looking at changing the pullup vales and experiment a bit more. 

Thanks

Vijay