ADS1015-Q1: I2C Write failure problem

Hi Alan,

Can you ask the customer to share logic captures of the transactions over I2C so I can verify they are sending and receiving data in the correct format?

Regards,
Joel

Hi Joel，

Thanks for your prompt response.

The I2C waveform was tested and found to be non-compliant with the specification. What could be the possible causes of this issue?

Hi Joel，

Update the test results:

Based on the waveforms captured after powering on, the host wrote the following values to the ADC-related registers and changed the values.

However, our software code does not include these behaviors.

Furthermore, although we can observe the corresponding I2C waveform during the write operation (for example, writing 0x8583 to the config register), the values read back from the registers do not match the written values.

What could be the possible causes of this issue? Please help analyze the possible causes of the above issues.

Hi Alan,

Can you confirm that the ADDR pin is pulled up to VDD? 

Can you also help by annotating the screen captures with the command they are expected to perform?

The first image looks to be a general call, followed by 0000 0110. This tells the device to enter power-down state. Since you are programming the device immediately after, I recommend removing this step. Can you send me the updated sequence after this change is made?

Regards,
Joel

Hi Joel，

Joel Meraz said:

Can you confirm that the ADDR pin is pulled up to VDD? 

ADDR pin is pulled up to VDD as shown below.

Below four screen captures happened after powering on.

The register values read from the device do not align with the reset default value  outlined in the datasheet(EXCEPT conversion register ).

What could be the possible causes of this issue?

Figure1(general call+ read conversion register =0000h, reset default value= 0000h )

Figure2(read config register =0100h, reset default value= 8583h )

Figure3(read Lo_thresh register =0000h, reset default value= 8000h )

Figure4(read Hi_thresh register =1B59h, reset default value= 7FFFh )

Hi Alan,

I think I have found the issue. The ADS1015 by default powers up into power-down mode to preserve power, and does not actively perform any conversions. To perform a conversion in single-shot mode, you will have to write to the Config register, and set the OS bit high. After the device powers on and initiates a conversion, it will then power back on again. This operation is described in section 7.4.2.1 of the datasheet.

The above also explains why reading from the Config register in the second picture you sent reads back 0x10, indicating the MODE bit is high, and that the device is single-shot mode or power-down state. I believe this may be expected when the device is in power-down mode, but it does look like the default should be 0x8583. I can confirm what the expected behavior should be after a general call reset.

The threshold registers are a little bit harder to explain. Interesting to note, the device looks to have enabled the conversion-ready function of the ALERT/RDY pin, as the Lo_threshold MSB is 0 and the Hi_threshold MSB is 1. 

As mentioned before, it might be interesting to observe if the general call + reset is causing any issues with the startup configuration of the device. Can this be removed, with the same sequence?

Another suggestion I have is to instead of having a restart condition after the address pointer register frame is sent, try sending a full stop condition, followed by a full start condition. Per the datasheet, it should work with either a stop condition or repeated start condition, but it is worth a try. The sentence below gives that indication, but the timing diagram only shows a stop condition, not a restart condition. 

" After the Address Pointer register is written, the target acknowledges, and the controller issues a STOP or a repeated START condition."

Similar advice for the register writes. After sending the address pointer register frame, can you send a stop condition, followed by a start condition? Below, the datasheet makes it seem that the stop condition is optional, and the register write may continue without it. This can be verified by adding the stop condition, then issuing a start condition and reading from the register.

"To change which register is read, a new value must be written to P[1:0]. To write a new value to P[1:0], the controller issues a target address byte with the R/W bit low, followed by the Address Pointer register byte. No additional data has to be transmitted, and a STOP condition can be issued by the controller. The controller can now issue a START condition and send the target address byte with the R/W bit high to begin the read."

Regards,
Joel

Alan,

In short, I would try removing and reapplying power to the device, so it starts in its default state, then executing the rest of the sequence with the general call + reset removed. I'm working on getting hardware so I can perform these steps myself.

Regards,
Joel

Hi Joel，

Pls allow me update Harman‘s reply：

We have identified the issue related to a sub-device connected to the I2C bus (topology shown in the diagram below).

When the PMIC branch of the I2C bus is disconnected, the ADC communicates normally and can be read/written without errors.

However, the addresses of the two sub-devices do not conflict: the ADC uses 0x49, while the PMIC uses 0x48. The root cause of the issue remains unclear.

Could you share any insights or suggestions on this matter? Thank you for your support.

Hi Alan,

Has the general call + reset command been removed? This instruction might not have defined behavior on the PMIC, so it could be causing issues. It would be worthwhile to check.

Regards,
Joel

Can you also share the part number for the PMIC device? There could be a case where both ADC and PMIC have control of the bus.