THS7353 - I2C issue solution step

Kawai,

What you propose will work fine. The end goal is to simply have the SCL line toggle 9 times at start-up. This clears the FIFO from any random states. We do not care what is on the SDA line duing this situation - mainly because the SDA line could be pulled low by the THS7353 upon power-up condition.

Cheers,

Randy

My customer can not resolve this problem yet.
I controlled the SCL after powering on THS7353, as follows.
For more information, please refer to the waveform.
The waveform of "SCL" is blue, and the waveform of "SDA" is yellow.
I think that this procedure is correct.
Could you please tell me advice.

Best Regards,

Kato

Kato-san,

I am seeing 8 SCL cycles and then somethign on the I2C bus is doing an ACK by pulling SDA low. I do not believe the THS7303 would do this, but most likely another device is doing this.

I would think that doing one more SCL sycle (9-cycles) will disengage the ACK state no matter what device is pulling the SDA line low. Once this is cleared, the system should be able to work normally by doing proper START conditions and programming as normal.

Please let me know if this works.

-Randy

Randy-san,

Thank you for the information.

We will ask our customer to add one more cycle of SCL.

-

Please let me ask you the some questions.

1) I'm understanding that TI recommendation is to toggle SCL 9 times (9 SCL cycles) to overcome the I2C design issue (Datasheet P.32), am I correct ?

2) Reffering the customer waveform, doesn't this have 9 SCL cycles  ?

3) When you toggle the SCL(9cycles), what should you do with the SDA ? Should you keep it low or just leave High, or doesn't matter ?

-

We're grateful for your help.

Best Regards,

Kawai

Kawai-san,

After looking more closely, you are correct. I do see 9 SCL cycles. I2C is usually negative edge triggered and this should be fine. However, the ACK state occured on the 9th negative edge. The only way to clear an ACK state is one more negative edge on the SCL. The only thing I can theorize is that the first negative edge engaged a Not-ACK state.

As for SDA, I would recommend to leave it high.

Cheers,

Randy

Randy-san,

It seems I2C is positive edge triggered.

I drew a picture of the I2C timing chart, so, could you please review whether it is correct ?

Please tell us the correct sequence if it is wrong.

Best Regards,

Kawai

Kawai-san,

I was looking thru the I2C specification and it does not specifically state if it must be positive edge or negative edge triggered. Rather, the SDA line transition must be stable during SCL logic high state (except for start and stop situations). If true, then it could vary from part to part.

As for the diagram, it appears to be correct except for the start and stop conditions. Technically, the SCL line should be held high (with no transitions) while SDA transitions for the event ot occur. Your shading is showing that SCL is transistioning during these conditions.

Cheers,

Randy

Randy-san,

Thank you for your great support.

I have revised the I2C sequence, so I appreciate if you could review the attached file ?

I'm asking the customer to test again following the attached file sequence.

When sending 8cycle of SCL, I drew both the case of sending "00h" and "FFh". Your recommendation was "FFh" but the datasheet description says "00h". I am understanding that the data wouldn't matter because the object is to just clear the 8bits of the FIFO buffer. 

Is there any reason that you had chosen the data "FFh" (SDA=All High) instead of "00h" (SDA=All Low) ? 

Best Regards,

Kawai

Kawai-san,

As you state. it really does not matter if it is 0x00h or 0xFFh. The I2C bus specification states that the 0x00h is a general call address and 1111 1xxx is reserved for future purposes. As such, systems generally do not care about these addresses.

As for the diagram, the Start and Stop conditions are now good. But, after looking at the bit sequence closer, technically the ACK state (SDA goes low or stays low) occurs after the 8th SCL bit. In your diagram, it shows going low after the 9th SCL bit. Now this is a a special "start-up" sequence and not the I2C standard bus specification. So as long as this is presented as the recommended "start-up" sequence, then I believe it is good.

Cheers,

Randy

Hello Randy-san,

I appreciate for your great help.

I understood the initial sequence what is needed for THS7353 is the following.

"Power up --> I2C Start Condition --> Send 8bit data (i.e. 00h, FFh) --> I2C Stop Condition"      (*1)

Now, when sending the 8bit data, THS7353 seems to pull SDA to Low in random timing. It seems this is because THS7353 power up in random state that device may have ACK engage in the 1st SCL or 2nd SCL or 3rd SCL or .....xxth SCL(until Stop Condition).

Here is the customer's question. I appologize to rushing you but please give us your comment/answer by tomorrow morinig (5/21 Japan time).

--------------------

[Question 1]

When sending the 8bit code (above *1, customer uses "FFh"), would there be only one random ACK (SDA=Low) ? Can you also guarantee that there would be only one SDA=Low at random timing from THS7353 ?

There is no such slave address which has one "0" on the I2C bus. If there would be more than one "0" which THS7353 pulls down during the 8bit code transmission, there is a possibility that other device may respond to this call.

---------------------

[Question 2]

 Sending the initial sequence of (*1) above, would there be the case below ?

  1) In the default state, THS7353 is in ACK engage that master would not be able to send "Start Condition".

  2) Before the "Stop Condition", THS7353 is in ACK engage that master would not be able to send "Stop Condition"

If there is a possibility for the above to happen, do you mean that the master needs to monitor I2C bus state and send one cycle on the SCL when I2C communication is stuck ?

--------------------

[Question 3]

Do you need to write all the register data of THS7353 after Power up ?

If you need to do this, we cannot understand the sequence when to do this, including (*1) sequence and maybe also one cycle of SCL. Could you tell us the total sequence from the beginning (from device power up) to overcome THS7353  known I2C issues ?

-------------------

Best Regards,

Kawai

Randy-san,

First, could I have your opinion for [Question 1] ?

Our customer will send the FFh code to clear the FIFO buffer, but during sending the code, THS7353 pulls down the SDA at some SCL timing (which seems to be THS7353 ACK, powering up at random state). This will change the data FFh  to something like 7Fh,BFh, DFh, EFh, F7h, FBh, FDh, FEh. Fortunately in the customer design, they do not have such slave address devices. However, if THS7353 pulls SDA=Low for more than 2 times in this 1 I2C sequence, one of the device on the I2C bus may respond and wait for the next 8bit data. The problem is that this would lead to the I2C miscommunication.

Could there be a possibility that THS7353 would pulls down SDA for 2 or more time when sending the 8bit code ?

Best Regards,

Kawai

Kawai-san,

1) There should be no reason for the THS7353 to pull the SDA line low for more than 1 SCL cycle. This is a result of an ACK state which is only active for one cycle only.

2) One hihgly probable condition is with the SDA line pulled low upon start-up. This is an ACK state. This is why the Master should ignore any errors upon start-up if it is monitoring the I2C bus. If the SDA line is pulled low at the end, then this is is a "normal" I2C situation and then one more SCL cycle clears the ACK which is a "normal" situation.Ideally, the initial start-up sequence discussed previously should be done wihtout montiroing the I2C bus or simply ignoring any errors during this initialization sequence.

3) After power-up and initialization, all 3 registers should be written to as they all can be in a random configuration.

The recommended sequence should be: 

 a) Initialization sequence as discussed previously

b) MAster does a START condition and then sends the THS7353 address (followed by a Write "0" bit) - which should be followed by the THS7353 perforiming an ACK at the proper point in the sequence. Write the Register address (followed by the ACK), and then the proper configuration code followed by an ACK and then STOP condition is performed by the Master.

c) Sequence (b) is performed for the other 2 registers.

d) THS7353 writing is complete.

I hope this is helpful.

Cheers,

Randy

Randy-san,

I apologize for my delay.

Thank you very much for your great support. It helped me very much.

Could I ask you a little bit more ?

-----

1) Can you guarantee that there would be only one SDA=Low toggle during sending the code(0xFFh) ?

   We asked customer to use 0x00h code, then I thought the THS7353 ACK would not disturb the communication. They had already tried this but the device on the bus had respond to the "general call address" which lead to communication error.

-----

2) If THS7353 powered up at ACK engage, I thing SDA is pulled low. In this case can the master send the Start Condition ?

  I think that SDA and SCL must be at High to send the start condition. In this case, master would not be able to start communication unless master sends one single SCL toggle. Am I correct ?

-----

3) Thank you very much. I understood.

-----

Best Regards,

Kawai

Kawai-san,

1) Yes, there should only be one SDA low bit at any given power-on condition sequence. I cannot think of any other reason for this to be low.

2) You are correct. This is why as part of power on reset "code" for the system, any errors due to SDA being low should be ignored. The goal is to simply clear out the FIFO bits in the THS7353 I2C core. Ther eis no "true" programming that should be done at this time - only after the power up sequence has completed.

Can you share with me the customer, application, and production target? you can send directly to me at r-stephens@ti.com if you wish.

Cheers,

Randy

Randy-san,

I apologize for my delay...

Thank you very much for the great support. It was a great help.

Best Regards,

Kawai