AM6422: Clarification on I2C_BUFSTAT usage — RXSTAT vs TXSTAT behavior in controller receive mode

Hello Wei Ding,

I checked in the AM64x/AM243x Processor Silicon Revision 1.0, 2.0 Errata but there is NO report for such an abnormal I2C_BUFSTAT.TXSTAT / RXSTAT behavior.

I have the following initial checkpoint questions:

Q1: Which one is the AM6442 I2C instance that you use ?

Q2: What is the configured I2C bus clock speed ?

Q3: What is the value of the pull-up resistors you use on the I2C_SCL and I2C_SDA ?

Q4: What is the VDDSHVx IO power supply voltage (1.8V or 3.3V) that you use for the AM6442 I2C pins ?

Q5: Shall I understand that exactly one I2C target and one I2C controller is connected to the I2C bus ?

Q6. Did you have the chance to check things from the I2C target register side (if possible) - does it successfully send the data to the AM6422 I2C controller ?

Q7. Do you have some oscilloscope images of the I2C bus the moment when controller reads data from the target ?

Q8. Does the  I2C_IRQSTATUS_RAW [3] RRDY bit polling shows that the I2C controller actually receives data.

Q9:  Is it a CPU polling or interrupt mode of I2C controller operation ?

Thanks for clarifying !

Kind Regards,

Anastas Yordanov

Hi Anastas,

Thank you for looking at this. Here are the answers to your questions:

Q1: Which one is the AM6442 I2C instance that you use ?  I2C0 and I2C1

Q2: What is the configured I2C bus clock speed ?  400 kHz (Fast-mode)

Q3: What is the value of the pull-up resistors you use on the I2C_SCL and I2C_SDA ? 4.7K (I2C0), 10K (I2C1)

Q4: What is the VDDSHVx IO power supply voltage (1.8V or 3.3V) that you use for the AM6442 I2C pins ?  3.3V

Q5: Shall I understand that exactly one I2C target and one I2C controller is connected to the I2C bus ? On each bus, there is one controller and multiple slaves connected.

Q6. Did you have the chance to check things from the I2C target register side (if possible) - does it successfully send the data to the AM6422 I2C controller ?  Yes, the data are received by the controller from the slave sensors.

Q7. Do you have some oscilloscope images of the I2C bus the moment when controller reads data from the target ?  No

Q8. Does the I2C_IRQSTATUS_RAW [3] RRDY bit polling shows that the I2C controller actually receives data. Yes, the I2C_IRQSTATUS_RAW[3] RRDY bit is checked during data read.

Q9: Is it a CPU polling or interrupt mode of I2C controller operation ?  Polling mode is used in this operation.

Thanks,

Wei

Hello Wei Ding,

sorry for I replied a bit later. Thank you for answering my questions.

It seems that from hardware point of view things are almost ok.

One important question is, have you enabled the pinmux control input buffers (in the corresponding PADCONF registers) of the I2C0_SCL and  I2C1_SCL pins (SoC level) ?

Q10. The I2C controller needs to monitor the generated clock for a clock-stretching exerted from the I2C target.  

Q11. Have you followed the settings in the Section, I2C Clocks / I2C Clocking,  Table: I2C Register Values for Maximum I2C Bit Rates in I2C F/S, I2C HS Modes of the AM64x TRM ?

Q12. How many bytes can you successfully read at the controller side ?

Thank you !

Kind Regards,

Anastas Yordanov

Hello Anastas,

For your questions above — yes, we have set up the I2C controller as per the TRM, and we can receive data from the slave sensors. As mentioned at the beginning, we observed that in the controller’s receive mode (when the master is reading from a slave), the TXSTAT field actually reflects the number of bytes received when the transfer ends, and we don’t know why. This can be seen in the snapshot from Lauterbach.

Thanks,

Wei

Hi Wei Ding,

"According to page 6569 of the AM64x / AM243x Processors Silicon Technical Reference Manual (Revision 2.0, Revision H), the I2C_BUFSTAT[13:8] RXSTAT field should indicate the number of bytes currently in the RX FIFO."

I suppose the AM6442 unsupported DMA mode is disabled from corresponding bitfield. Correct ?

From what we have on page 6569 of the TRM I am a bit confused about the behavior of TXSTAT and RXSTAT register bitfields  in the polling mode (highlighted in green).   Are these register bitfields updated with actual number of bytes in FIFOs upon each byte transmission and reception or they only show the initial number of bytes to be transferred and cleared, synchronized on a completion event, after all bytes are transferred. Do you have any observations on TXSTAT value update for the I2C controller transmit process ?

"For your questions above — yes, we have set up the I2C controller as per the TRM, and we can receive data from the slave sensors. As mentioned at the beginning, we observed that in the controller’s receive mode (when the master is reading from a slave), the TXSTAT field actually reflects the number of bytes received when the transfer ends, and we don’t know why."

So I suppose then that your software exactly follows the Figure 12-132. I2C Controller Receiver Mode, Polling Method, in F/S and HS Modes of the  Section, I2C Programming Guide / Subsection, I2C Programming Model of the AM64x TRM. Correct ?

I will need to  internally discuss on the exact TXSTAT and RXSTAT behavior with our I2C hardware & low level software driver experts. Please expect a possible delay in the reply.

Thanks for your patience !

Best Regards

Anastas Yordanov

Hello Wei Ding,

Sorry for my delayed response.

I have got a confirmation from the expert that:

The RXSTAT bits should tell the amount of data to be received by the I2C controller. The TXSTAT bits should tell the amount of data to be transmitted by the I2C controller. 

Can you please kindly confirm on the correct mapping of the I2C_BUFSTAT,  TXSTAT and RXSTAT strings to the corresponding monitored AM6442 register address and bitfield positions as per the Lauterbach host application register definition file.

I am waiting for your feedback !

Regards, 
Anastas Yordanov

Hello Wei Ding,

Please refer inputs i received from the design team:

I2C is configured as master receiver for 7 bytes.

From spec:

TXSTAT = DCOUNT – TXFIFO. Note: This DCOUNT gets decremented during FIFO operations.

RXSTAT = Number of received bytes currently present in RX FIFO and not yet drained by CPU read.

From simulation:

Case 1: DCOUNT = 7, TXFIFO is empty

Received 7 bytes and RDR is set due to Stop condition.

Read BUFSTAT : RXSTAT = 7 as 7 bytes received, TXSTAT = 7

Read 1 byte: Read BUFSTAT : RXSTAT = 6 as 7 bytes received, TXSTAT = 6

Read 2 byte: Read BUFSTAT : RXSTAT = 5 as 7 bytes received, TXSTAT = 5

….

Read 7 bytes: Read BUFSTAT : RXSTAT = 0 as 7 bytes received, TXSTAT = 7

Note: Internal DCOUNT counter reloads with configured original DCOUNT register value once it reaches 0.

Conclusion:

RX STATUS value depends on the current number of received bytes. It becomes 0 with all bytes read.

TX STATUS as shown above is dependent on the DCOUNT – TX FIFO.

Regards,

Sreenivasa