AWR1843BOOST: I2C can not generate STOP condition

Hello Yafeng,

Can you do the capture using the analog ports of the oscilloscope so that the actual signal levels, rise/fall times etc. can be seen? I assume the above capture is using the digital ports.

regards,
Vivek

HI,Vivek

The waveform captured by the oscilloscope analog ports is as follows:

Normal situation:

Abnormal situation:

SCL & SDA:

Raise Time: <180ns, Fall Time: < 60ns

Thank you

YAFENG

Hello Yafeng,

Sorry for the delay. It's taking some time to research this, and hence we would like to Thank you for your patience. 

We will surely get back to you by mid next next week.

Regards,

Ishita

Hi Ishita, Yafeng,

I can speak on behalf of TMP112 and the Temperature Sensing team within TI. What I see in the plots is that TMP112 responds correctly in both the Normal and Abnormal cases. The host provides a NACK after the 2nd byte, to indicate it does not wish to receive further data from TMP112. It's not clear to me why the I2C host decided to Stop in the Normal case, and decided to halt further communication in the Abnormal case.

thanks,

ren

Hello Yafeng,

Could you answer the below questions to help us understand this issue better :

1. For your usecase, the AWR device is the master here correct?

2. What is the frequency at which you're running this?

Looking forward to hearing from you.

Regards,

Ishita

Hello Ishita,

1. For your usecase, the AWR device is the master here correct?

Yes, the AWR device is the master,

2. What is the frequency at which you‘re running this?

100kHz, my Initialization code of I2C as follow:

Thanks

YAFENG

Hello Yafeng,

We're running some tests on this internally, will need some more time to get back to you.

Thankyou for your patience.

Regards,

Ishita

Hello Yafeng,

Here are our observations after running some simulations:

1. If you refer to the register "ICMDR" <bit:15> NACKMOD: When I2C is in master mode, it will automatically generate a Nack when ICCNT goes to zero (ie, data is fully received).

2. In the abnormal case, we can see the SCL bit is not toggling because, the SDA bit should go low first. Only after SDA bit for the current NACK signal goes low, the SCL can toggle again. This is confirmed in our tests as well.

3. The SDA bit after receiving the NACK, will go into RESTART_OR_STOP phase in the FSM and will be waiting for the user to program a register bit in-order to stop the transfer. Once the "STP" bit in ICMDR is programmed, it will generate the stop signal and hence SDA will go low as long as there is no restart condition and SCL also toggles. How are you writing the STP bit of the MDR register in your application?

Please check the values of the above registers in your normal and abnormal case and let us know your observations.

Regards,

Hello, Ishita

In normal case, I2C Registers（This is a GIF, you can download it）:

In abnormal case, I2C Registers:

I am using the 03.01.01.02 version of the mmwave_sdk , I2c driver has not been modified, using TI native code.

YAFENG

Hello Yafeng,

At what instance are these screenshots taken? Because I can see the STP bit as '1' for one case while it's '0' for the other one.

Regards,

Ishita 

Hello, Ishita

The first screenshot is a GIF, after uploading, it became a png, and I re-uploaded a compressed package，there is a GIF picture inside.iic.zip

In abnormal case, STP will be set to 1, but will not automatically become 0. in normal case, STP will become 0 after the STOP bit is generated.

YAFENG

Hello Yafeng,

Sorry for the delay, we're researching and trying to replicate this issue on our end these days. Thankyou for your patience. I have a couple of questions as well some workaround for this.

1. How often are you seeing this failure? Is it like very often or rarely once in a run?

2. Also, if you encounter this abnormal condition again, can you explicitly write to the STP bit and see if it recovers?

3. Can you also share the code snippet for your case.

Regards,

Ishita 

Hi，Ishita

Sorry for the delay, Basically this problem will occur once it runs.I will provide the test code to reproduce the problem later.

Yafeng

Thanks Yafeng,

Please do try writing the STOP bit after the problem occurs to see if it recovers or not. Let us know your insights.

Regards,

Ishita

Hi, Ishita

I wrote a test code to test this problem, but there is no abnormal situation,

But in our system, it appears very frequently. I rewritten the i2c driver to avoid this problem, and it seems to have been resolved.

Thanks for your attention.

Yafeng