I2C Write/Read Test Case – Always Getting NACK (Need Help)

[sanacdac]

I am working on an I2C test case using LabVIEW + PXI Digital Pattern instruments, and I am consistently receiving NACK instead of ACK from the DUT. I want to share my complete setup and flow so the community can help identify what might be wrong or suggest better approaches.

---

🔧 Hardware Setup

PC (LabVIEW Application)
  ↓
PXIe-1092 Chassis
  • Slot 3: PXIe-6571 (100 MHz Digital PPMU – used with Digital Pattern Editor)
  ↓
Breakout Box
  ↓
Device Under Test (DUT)

📌 Test Flow

1. Initialize Session

• Provide the instrument name and slot for the PXIe-6571.

• Initialize the Digital Pattern session.

---

2. Power ON the DUT

• Supply voltage and current limits based on the DUT datasheet.

• Configure the required pins in PPMU mode.

• Apply the voltage to power up the DUT.

---

3. Stabilization Delay

• Insert a small wait to allow the DUT to power up and stabilize.

---

4. Power Verification

• Measure the voltage and current.

• Confirm that the DUT is receiving the correct power (no drop or overload).

---

5. Load Test Resources

• Load the Pin Map file.

• Load Specification Levels.

• Load Timing (I2C timing specifications).

• Apply levels and timing to the session.

• Load the Digital Pattern (.digipattern) file.

---

6. Create & Write Source Waveform

• Use Create Source Waveform and Write Source Waveform to send dynamic data.

• The waveform contains the I2C write data (Address + Register + Data).

---

7. Burst the Pattern

• Execute the I2C Write pattern using Burst Pattern.

• Enable capture on the 9th bit for ACK/NACK sampling.

---

8. Fetch Captured Data

• Fetch the actual captured samples from the DUT.

• Extract the 9th-bit samples to determine ACK/NACK.

• Currently, I am receiving NACK for every transaction.

---

9. Sample Count

• Read the number of samples captured.

• Confirmed that the samples match the number of expected 9th bits.
  
  
  

  ❓ What I Need Help With

  1. Is there anything wrong or missing in my test flow?

  2. Does PXIe-6571 require a specific pull-up configuration for I2C?

  3. Could my pin-map or pattern timing be incorrect?

  4. Is there a better method to capture ACK/NACK?

     • Example: Capturing all vectors and parsing ACK bits later

  5. Any suggestions for debugging I2C using the Digital Pattern Editor?
     
     

     👉 If you know any other method or approach, please let me know!

[santo_13]

What is your goal? to do DUT register read/write over I2C using 657x?

SDC addon is simple to use out of the box

[sanacdac]

Hi Santhosh,

Yes, my goal is to perform DUT register read/write over I2C using the PXIe-6571 with the Digital Pattern Editor.

We are developing a protocol-validation setup, so we need to validate the DUT’s I2C behavior at the raw signal level using digital patterns, not higher-level drivers.

I am manually generating the full I2C sequence
(START → Slave Address + R/W → Register Address → Data → STOP) and capturing the ACK/NACK on the 9th bit.
The pattern bursts correctly, but I consistently receive NACK, so I want to understand:

• Whether using Digital Pattern + source waveform is the correct approach for low-level I2C protocol validation, and

• If there are better ways on 657x hardware to reliably capture the ACK/NACK
  (e.g., compares, full-vector capture, adjusting compare/sample timing, or any recommended practice for open-drain protocols).

Regarding SDC:
For this project we cannot use SDC, because we need full visibility and control of timing/patterns for protocol validation.
So we need to continue with manual pattern-based I2C generation.

Any suggestions or alternative methods would be very helpful.

Thanks!

[LV_Tim]

Hi,

I have not used that card before but I have implemented i2c from first principles on a FPGA and I get the frustration.

First are you sure the UUT is NACKing? I would check your signal with a scope.

Secondly, check the timing of your NACK read, you might be reading immediately after the last bit and the UUT hasn’t responded yet. Try delaying the read by 1/2 a bit width, the i2c requires the read mid bit.

Thirdly, are you sure you are tri-stating or changing your output to an input before reading the NACK?

[santo_13]

---

@sanacdac wrote:

Hi Santhosh,

Yes, my goal is to perform DUT register read/write over I2C using the PXIe-6571 with the Digital Pattern Editor.

We are developing a protocol-validation setup, so we need to validate the DUT’s I2C behavior at the raw signal level using digital patterns, not higher-level drivers.

I am manually generating the full I2C sequence
(START → Slave Address + R/W → Register Address → Data → STOP) and capturing the ACK/NACK on the 9th bit.
The pattern bursts correctly, but I consistently receive NACK, so I want to understand:

• Whether using Digital Pattern + source waveform is the correct approach for low-level I2C protocol validation, and

• If there are better ways on 657x hardware to reliably capture the ACK/NACK
  (e.g., compares, full-vector capture, adjusting compare/sample timing, or any recommended practice for open-drain protocols).

Regarding SDC:
For this project we cannot use SDC, because we need full visibility and control of timing/patterns for protocol validation.
So we need to continue with manual pattern-based I2C generation.

Any suggestions or alternative methods would be very helpful.

Thanks!

---

If you're validating the protocol using 657x, we got the right software for you to skip your efforts and get the business done,
I2C Protocol Validation Suite | Soliton Technologies

Please share your details over direct message and I will pass on the info for a demo.