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.

TLA2024: The reason why the I2C W/R commands repeat

Part Number: TLA2024

Hello,

My customer uses TLA2024.  They found the same W/R commands repeated a few times as shown in the attached.  Would you please give me your comments for the followings?   Note that they use default register settings.  They checked SCL both 100kHz and 400kHz.

1. Would you please tell me if the behavior they saw is expected or not?

2. If it is, would you please tell me the reason why it repeated a few times?

3. Would you please tell me how to fix this issue?  They expect one time for W/R registers.

TLA2024_I2C_2021Sep30.xlsx

Best Regards,

Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    Looking at the SDA and SCL images you provided in the Excel sheet, there seems to be some issue with the acknowledgement from the ADC. After every bye of data sent, and extra clock pulse is needed and this will cause the device to either acknowledge the data or not acknowledge the data. In your scope capture, it seems that there are some instances where the device is not acknowledging the data being sent on the SDA line and this could cause some issues. 

    To better help debug, can you please provide a close up capture of the first byte of data sent so we can see the SCL and SDA timing more clearly? With this, we can check to see that both SDA and SCL are meeting the timing requirements for proper I2C communication. I think it would also be beneficial if you can include a relevant portion of the schematic. Additionally, are there any other devices on the I2C bus? 

    Regards,
    Aaron Estrada

  • Hello Aaron-san,

    Thank you very much for your reply.  I'm checking their system now and schematic, but do you think you would be able to provide me what would happen if TLA2024 gets the half pulse on SDA after ACK like this case?  I know it's unexpected pulse, but my customer expects ignoring such pulse.  However it looks the pulse might have caused repeating the commands.

    Best Regards,

    Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    I think this pulse is expected. After the TLA acknowledges data, the line is released and the controller has to start driving the SDA line again. I believe this is what causes the pulse. 

    Looking at SCLK again, it looks like period changes. There are some clock periods that are longer than others. I will await the schematic and close up of the I2C timing. 

    Regards,

    Aaron Estrada

  • Hello Aaron-san,

    Thank you for your comments again.

    You said in your first reply that "it seems that there are some instances where the device is not acknowledging the data being sent on the SDA line and this could cause some issues".  I thought it is the half pulse after ACK, but you said it is expected.  Would you please tell me exactly where the "some instances where the device is not acknowledging" are?  I thought the SDA line will stay low after ACK if the next data(D7) on SDA is low.

    Best Regards,

    Yoshikazu Kawasaki

  • Hello Aaron-san,

    I found the instances you mentioned like the one after 2nd 0x83 at 400kHz.  I'll ask you to check their schematic and detail waveforms once I get those.

    Best Regards,

    Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    Thanks for the update. I will await the detailed waveforms and their schematic. 

    Regards,
    Aaron Estrada

  • Hello Aaron-san,

    I got detailed waveforms and their schematic as attached.  It looks to me it just takes that much longer conversion time, but the conversion time shown in the datasheet is only 1/DR.  Could you please check it and give me your comments?  Note that my customer checked the timing requirements shown in the datasheet on page 6, but they didn't see any violations.TLA2024_I2C_2021Oct08.xlsx

    Best Regards,

    Yoshikazu Kawasaki 

  • Hi Kawasaki-san,

    Thank you for sending this over. After taking a closer look at the I2C transactions, I am a bit confused on some things. 

    1. After configuring the configuration register with a value of C583, there is another write to the device that point to the configuration register that seems unnecessary. The reason why I say unnecessary is because there is no data sent after pointing to this register. Why point to the configuration register again and not configure it?

    2. After pointing to the configuration register a second time, there is read transaction done. The first frame looks good as you send the correct I2C address but the second frame doesn't make any sense. Here you should point to either the configuration register or the conversion register. Here you point to the register 0x45 but there is no such register. Can you elaborate here on what you are trying to do here? I am not sure where the 0x83 comes from as the device somehow transmitted this data but there is an NACK after and I am not surprised there is due to the register you pointed to. 

    So ultimately, it looks like you can get rid of the second transaction that points to register 0x01. If you wish to read the conversion results, you need to point to register 0x00. 

    Regards,
    Aaron Estrada

  • Hello Aaron-san,

    I got my customer's reply about your comments.  Would you please check the attached and give me your comments again?  It looks their register settings are correct.

    #1:Even if the read operation, it needs to configure slave address with W as the datasheet figure 12 says if I understand correctly.  Therefore there is no data required after the 2nd pointer(0x01).  Would you please tell me if I'm wrong?

    #2:The 0x45 you pointed should meet the datasheet figure 12 because it is the register data(MSB) and LSB will end with NACK as the datasheet says /A.  They did 2nd read operation because it returned OS=0(performing a conversion).  Would you please tell me if I'm wrong?TLA2024_I2C_2021Oct12.xlsx

    Best Regards,

    Yoshikazu Kawasaki

  • Hello Kawasaki-san,

    Understood. I was misinterpreting the scope shots. Thank you for clarifying. This seems to be expected. Bit 15 in the configuration register can be polled to see if the device is currently performing a conversion. What the customer is seeing seems to be expected. 

    Regards,

    Aaron Estrada

  • Hello Aaron-san,

    Thank you for your comments again.  I have 2 questions.

    1. If their results are aligned with the register procedure, would you please tell me the reason why it took that much conversion time even though the datasheet says "Conversions in the TLA202x settle within a single cycle, which means the conversion time equals 1 / DR"?

    2. Would you please tell me how they can minimize the conversion time to read the register?

    Best Regards,

    Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    When using power down mode, you need to account for not only the conversion time but an additional 10% of the conversion time for the internal oscillator as well as ~25us for the ADC to power on. With a DR of 1600SPS, you can expect a conversion time of roughly 712us. Does this align with what the customer is seeing?

    Regards,

    Aaron Estrada

  • Hello Aaron-san,

    Thank you for your quick reply again.

    Yes, they should use power down mode since they said it's in single shot mode and their-plots actually show MODE=1.  I understand if they would like to minimize the time to get the conversion results, they need to do one or both of these.  Am I correct?

    1. Mode change to Continuous Conversion Mode by MODE=0

    2. Changing the data rate by DR[2:0]=11x(3300SPS) from 100(1600SPS, default)

    Best Regards,

    Yoshikazu Kawasaki

  • Hello Kawasaki-san,

    That is correct. 

    1. By using continuous conversion mode, the ADC does not have to power down and will save some time. 

    2. By increasing the data rate to 3300SPS, the conversion time will decrease by ~1/2 the time when using a 1600SPS data rate. 

    Regards,

    Aaron Estrada

  • Hello Aaron-san,

    Their evaluation results showed around 1ms at 400kHz and 2ms at 100kHz which doesn't align with what you said that it took roughly 712us.  Do you really think their register settings are correct?  If so, would you please tell me why their results showed different conversion time depending on the SCL frequency?

    Best Regards,

    Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    The times I provided were the conversion times of the device and the time for I2C transactions was not taken into consideration. For writes, you can use (32bits / I2C clock rate) and for reads, you can have 45bits / I2C clock rate). This along with the conversion times should get you closer to the times the customer measured. 

    Regards,

    Aaron Estrada

  • Hello Aaron-san,

    Thank you very much for your comments.  It makes sense, but the number of bits for writes should not be 32bits, but 9bits(incl. ACK) x 4commands = 36bits since reads should include ACK by 9bits x 5commands = 45bits.

    Best Regards,

    Yoshikazu Kawasaki

  • Hi Kawasaki-san,

    You are correct! Sometimes the harder math makes more sense that the simpler math Slight smile

    Regards,

    Aaron Estrada