LDC1612: NACKs final CONFIG byte when exiting Sleep mode despite valid ID and reset-register reads

Hi Nikolaus,

I would be happy to assist you with your issue.

1. CONFIG=0x0801 is valid and is a correct way to exit Sleep with internal oscillator.
2. The LDC1612 does not intentionally NACK a valid CONFIG write. There is no documented behavior for this.
3. A disconnected or non-oscillating coil cannot cause an I2C NACK. It only sets error flags in the STATUS register.
4. Your understanding is correct, sensor errors appear in STATUS. The I2C bus does stay operational.
5. No special timing required on the bus after the CONFIG write. The device handles the wake-up sequence internally.
6. Reset defaults are fine for a basic test. No need to program RCOUNT/SETTLECOUNT/CLOCK_DIVIDERS first.
7. 1 µF + 10 µF decoupling is fine.
8. Let me look into providing you with this information.

All of those signals should be helpful in debugging this issue.

Also if you are able could you please provide me your coil information?

If you have any additional questions in the meantime please let me know and I would be happy to assist.

Regards,
Chase Girard

Hi Chase,

Thank you for looking into this.

The two coils are hand-wound around a non-magnetic 3D-printed coin channel.
Each coil has approximately 20 turns of 0.2 mm enameled copper wire.

LDC1612 Channel 0 (IN0A/IN0B, connector J2):

• Measured inductance: approximately 13.0 µH
• Parallel tank capacitance: 5.7 nF (4.7 nF + 1.0 nF)
• Calculated ideal resonance frequency: approximately 585 kHz

LDC1612 Channel 1 (IN1A/IN1B, connector J3):

• Measured inductance: approximately 12.2 µH
• Parallel tank capacitance: 1.22 nF (1.0 nF + 220 pF)
• Calculated ideal resonance frequency: approximately 1.30 MHz

The failure has occurred with both coils connected as well as with both coils disconnected.
I have not yet measured the coil resistance, Q factor, or self-resonant frequency.
Please let me know if you need these values or the physical coil dimensions.

Based on your information, I will now focus on determining whether the LDC1612 actually drives SDA high during the ACK bit or whether the STM32 reports the NACK incorrectly.

I will try to capture the CONFIG=0x0801 transaction using:

• CH1: SCL
• CH2: SDA
• CH3: INTB
• CH4: LDC1612 VDD

Could you please provide the known-good minimal transaction information mentioned in point 8, and let me know whether you would like any specific trigger condition, sample rate, voltage threshold, or additional waveform detail?

Regards,
Nikolaus

Hi Nikolaus,

I am still looking for the information you requested and I will provide it to you once I have located it. I would recommend always testing with the coils connected to prevent any unrelated issue. The Q factor and actual coil dimensions would be helpful as well. Also, please send me the scope captures for those signals. If you have any questions in the meantime, please let me know.

Best regards,
Chase Girard

Hi Chase,
thank you. I have now captured SCL, SDA, the LDC1612 VDD directly at the local decoupling capacitors, and INTB simultaneously.
I also reduced the firmware to one deterministic transaction so that the first failing transfer is unambiguous.

Test conditions:

• 10 kHz I2C, 4.7 kOhm pull-ups to 3.3 V
• ADDR, SD, and CLKIN tied to GND; internal oscillator selected
• No I2C scan, no MCP23017 access, and no LDC register read before the write
• First and only initial transaction:
  START -> 0x54 -> 0x1A -> 0x08 -> 0x01 -> STOP
• 100 ms later, the firmware makes one diagnostic read attempt for each of CONFIG, STATUS, DATA0_MSB, DATA0_LSB, MANUFACTURER_ID, and DEVICE_ID

Observed result:

1. 
   In figure_1_config_write_ack_nack.png, the first two address bits are outside the stored pre-trigger window, but all remaining 34 clock positions match the expected 0x54, 0x1A, 0x08, 0x01 sequence. The LDC acknowledges address 0x2A and register pointer 0x1A.
   It does not acknowledge either CONFIG data byte: 0x08 receives NACK and 0x01 receives NACK.
   The low level generated by the LDC during the two earlier ACK bits is approximately 0.76 to 0.80 V, whereas an SDA low driven by the STM32 is close to 0 V.
2. 
   figure_2_vdd_intb_during_config_write.png shows the same failed write with VDD and INTB. VDD remains at approximately 3.25 V on the oscilloscope (3.29 V by multimeter) and has no dip correlated with either NACK. Across the complete captures, the 102.5 us moving-average VDD span is only 18 to 21 mV.
3. 
   In figure_3_post_write_address_nacks.png, the diagnostic register-read attempts made 100 ms later receive NACK on address 0x2A. SCL and SDA return high between attempts; the bus is not stuck.
4. 
   figure_4_intb_capture_comparison_a.png and figure_4_intb_capture_comparison_b.png show an additional observation on INTB. With ERROR_CONFIG at its reset value, I expected the push-pull INTB output to remain actively high. Instead, both captures contain rounded, quasi-periodic analog dips. They are not valid low states: the minimum was 0.916 V in one run and 2.211 V in the repeated run, rather than <=0.4 V. The substantially different depth suggests measurement pickup, a floating net, or an abnormal output driver rather than valid LDC interrupts.

INTB is wired directly to an STM32 input configured without a pull resistor.
No EXTI is enabled and the minimal test neither reads nor acts on INTB, so INTB cannot alter the I2C sequence.

These particular captures were intentionally taken without coils solely to isolate the bus transaction, based on the earlier clarification that a missing or non-oscillating coil should only set status flags and should not cause an I2C NACK.

As mentioned in my original post, the two hand-wound coils measure approximately 12.2 µH and 13.0 µH. Each has about 20 turns of 0.2 mm enamelled copper wire and a DC resistance of approximately 1.1 Ω. I will provide the measured Q factors and verified coil dimensions as soon as they are available.

Could you please review the attached captures and advise what failure mechanism they suggest?
Two observations I cannot resolve from the data sheet are the LDC-generated SDA ACK-low level of approximately 0.76 to 0.80 V with a 4.7 kΩ pull-up to 3.3 V, and the rounded analog dips on INTB, which I expected to remain actively high with ERROR_CONFIG at its reset value.
After the failed CONFIG write, the device also stops acknowledging its address although SCL, SDA, and VDD remain valid. Are these observations consistent with any known device state, or do they suggest a connectivity problem or damaged LDC1612?
What single decisive measurement would you recommend before replacing the device?

I have attached the cropped PNG figures and the original four-channel CSV files (scope_4.csv and scope_5.csv).
scope_5.csvscope_4.csv

Best regards,
Nikolaus

Hi Nikolaus,

I am currently out of office so responses may be delayed at this time.

Looking at what you have provided me I am smuggling to see anything that is sticking out to me as incorrect. While I continue to review these waveforms, without doing any configuration could you do a read back of the data registers with and without the inductive coils?

Thank you,
Chase Girard

Hi Chase,

I completed the requested unconfigured DATA-register readback after separate power-on resets, first without coils and then with both coils connected.
The firmware performed no register writes and no I2C scan.

Both runs produced the same result:

All reads returned successfully and repeated DATA reads remained unchanged.

We have also isolated the next transition: communication is stable with the internal-clock configuration `CONFIG=0x3401` while Sleep remains enabled.
When only `SLEEP_MODE_EN` is cleared by writing `0x1401`, the write receives NACK.
The device becomes reachable again after about 100 ms with `CONFIG=0x2801`, `ERROR_CONFIG=0x0000`, and `STATUS=0x0000`.

How do you interpret the identical unconfigured DATA-register results with and without coils together with the observed reset-default state after the failed Sleep-to-active transition? What would you recommend as the next diagnostic step?

Best regards,
Nikolaus

Hi Nikolaus,

Thank you for running these tests. May I ask have you only tested with a single LDC1612 unit? If possible I could you attempt to replace the LDC1612 and retest to see if the issue persists?

Best regards,

Chase Girard