Positron BASIC Community

I analyzed the I2C data from the device that controls the APW9 power supply unit, obtained the data, wrote a program to scan the device's address, and got 10 — which matches the logic analyzer. However, the data includes address 8, to which the APW9 returns a NACK. I'm trying to transmit the data obtained from the logic analyzer to my own device, but the APW9 doesn't change the voltage. The device from which the data was collected by the logic analyzer was set to 15 V, and it works.
Maybe I didn't understand something and made a mistake in analyzing the logic analyzer data; I'm attaching the logic analyzer file — maybe someone can help me figure it out.

The program used for the analysis: https://discuss.saleae.com/t/logic-2-4-45/3788

And here, the I2C is operating at a frequency of 330 Hz, as shown by the logic analyzer.

Thank you.

I reviewed the salea file

from AI

(In computer networking and message queues, ACK (Acknowledgement) is a positive response showing data was received successfully, while NACK (Negative Acknowledgement) is an error signal telling the sender that data is missing, corrupted, or failed to process)

when transmitting either first or last byte sent return an error (NACK)

it will help if you can post your code to transfer the I2C
and verify the polarity eg: starting from an High or Low when transmitting.

if this is any help, let us know.

The logic analyzer file contains 9 packages, and only in package 3 does it return NASK, but there is no such address 8 during scanning, and here it returns the NASK register; in package 6, it also returns NASK in the data. But in package 4, strangely, this address is present. I don't understand anything. Maybe it's transmitted in words here, not bayte.

It's strange that, despite the same set voltage of 15 V, the data from the logic analyzer differs.

If you analyze it in bit format, it doesn't match what the logic analyzer provides — it says C8, but if you analyze it, you get D0; it's unclear.

If you analyze it in bit format, it doesn't match what the logic analyzer provides — it says C8, but if you analyze it, you get D0 — it's unclear. The second screenshot also doesn't show what you expect, or am I calculating it wrong?

Or is there only one address here, and the rest are registers and data, and also I2C_ReStart() is used here?

The Microchip Technology PIC16F628A does not support hardware I2C because it lacks a built-in
Master Synchronous Serial Port (MSSP) module

How Software I2C Works on PIC16F628APins:

Use any two general-purpose I/O pins (such as RB0 for SCL and RB1 for SDA).

Control: Toggle the TRIS register to switch the pins between an input (releasing the line) and an output low (pulling the line down).

Pull-up Resistors: Add external pull-up resistors (around 4.7 kΩ) to the SDA and SCL power lines, as software emulates open-collector outputs.

Limitations: This software method lets your PIC act as an I2C Master to read sensors or displays, but implementing an I2C Slave in software is much more difficult.

Explore a software code example and address scanning guide from Interfacing I2C LCD with PIC: Bit-Bang Reset & Address Scan.


Normal Protocol NAKs

End of a Read Operation:
 If the master device is reading data from a slave, the I2C rules state that the master must send a NAK on the very            last byte before sending the stop command.

This tells the slave to stop sending more data

Error or Busy NAKs During Writes

If you are writing data to a chip like an EEPROM, it might return a NAK because it is still busy processing the previous write cycle internally and cannot take new data yet.

Unsupported Command:
 The slave device received a data value, register address, or command that it does not recognize or support

Buffer Overflow:

 The internal memory buffer of the receiving slave device is completely full

Electrical or Timing Issues:
 Poor signal quality, incorrect clock speed, or bad pull-up resistors can corrupt the signal, causing the device to misread the byte

Also it might help to add a delay right after I2C_Start(), I2C_Stop()

If can get a PIC with MSSP this can help find the reason.