ADN4605 channel status registers

Hi Dhananjay,

I believe this may be a hardware issue. The software writes/reads look correct and the fact that you are able to read the correct values in some of the registers indicates that you are properly communicating to the device. I noticed on the schematic that the CSB pin is left floating. This pin gates the update so this needs to be pulled low in order for the XPT update to take effect. Please give this a try. I believe this should correct your problem.

Regards,

Jarrod

Hi Jarrod

As per your suggestion, I pulled down chip select (CSB) as well as update pin. Still I see 0x3F in channel status registers.

  Please help me to debug this.

with regards

Dhananjay

Hi

  Is there any way to debug this board further?

Dhananjay

Hi Dhananjay,

have you solved the issue?

I'm facing to similar one. Time to time I've seen wrong behavior, the writes go to the wrong register or read returns values from different or nonsense. I must admit it might be caused by problematic layout of the i2c bus on the PCB. Anyway it seems the switch (according to the scope) might responds with wrong values.

Regards,

Petr

Hi,

Apologies, I lost visibility to this thread as it was presumed to be answered correctly. With regards to intermittent behavior, can you please provide a scope shot of the I2C Data and Clock Lines? Have you verified that that register address and data on the scope are the same  as in software? Also, can you verify the logic levels of the I2C signals along with the DVCC supply voltage level? The ADN4605 will not internally write data to the wrong registers unless the data has been corrupted. This can be due to noise on the power supply (DVCC), improper power supply level, or incorrect control logic level. Other impairments can play a role as well, such as XTALK on the I2C bus. If you would like to share your schematic, I will be happy to review it.

Regards,

Jarrod

Hi Jarrod,

Thank you for reply

Yes, I've verified the i2c messages which comes from microcontroller are correct. Voltage levels seems to me correct (see below). I've also tried to repeatedly read the whole register set and compare it with stored one, what I've observed is that time to time the different value has been read. I've ended with correction task which compares registers with stored configuration and tries to correct errors, it runs until all reads are correct. So far this fixes all problems. Anyway it's kind of workaround.

DVCC 3.3 V: noise 50 - 60 mV (switched power supply)

I2C communication:

I2C detail: ~50 kHz, 3.2 V hi level, small crosstalk on SDA

See attached file for the schematic page (2.2k pull-up resistors for i2c are on another page).

Thank you,

Petr

Hi Petr,

Thank you for the scope plots and the schematic. The power supply noise ripple of 50mV to 60mV is well within the supply tolerance range of +/-10%. The I2C voltage swing levels look correct. I do see XTALK on the SDA line. There is coupling from the SCL to SDA lines. It looks marginal on these scope plots, but if by chance the XTALK coupling was strong enough to create a gltich on the SDA line that is large enough to trip the mid level of the internal transistors (DVCC/2) then this could corrupt the I2C write/read and potentially generate a false start/stop condition. This could create the indeterminacy that you are experiencing. The plots you provided do not indicate that the magnitude of the SDA signal glitch is large enough to create this problem, but this could be dampened by the probe. It is something to look out for.  Other than this, everything else looks fine from a logic timing, level, and noise perspective. Can you please explain more about your correction task/workaround  and how it works? Do you just continue to write to the same register until you readback the correct value?

Regards,

Jarrod

Hello Jarrod,

The cross talk between SCL and SDA is probably the main reason of wrong behavior. The probes damped the signal little bit as they have capacitance of 10 pF. Anyway I'm quite sad the chip sends nonsense (read as: data that is not in any register).

The correction is relatively simple: After every change in configuration, the correction task is started. The correction task reads all registers in chip and compares read data with stored configuration, when mismatch is detected, the value in particular register is corrected and additional iteration of the correction task is requested. When all reads are correct, the correction task is stopped.

The simple readback is not possible, because as I've observed, the value is rarely written to the wrong register, so whole register set check has to be done.

Regards,

Petr

HI，I   met the same problem.but when i pull  up the update pin i read the register(0x54-0x7b),reback 0x00-0x27,can u tell me  where is the debug?  it(0x54-0x7b) must reback 0x00 if there  are no prbolems?