I2C monitor function in LPC812

[_Nathan]

Hi All,

I want to use the I2C Slave of LPC812 to monitor the communication between other Master and Slave, but I2C Slave of LPC812 should response with a NACK when a SlaveAddress or DataByte received(Because it should not affect the ACK of other Master and Slave).

I have tried call Chip_I2CS_SlaveNACK() after a SlaveAddress or DataByte received, but it sames that the state machine of the I2C slave have stopped and cannot continue to monitor data from I2C Bus.

Is there a solution to this problem?

[xiangjun_rong]

Hi,

Based on my I2C knowledge, when the I2C receiver has  received a byte(no matter whether it is an address byte or data byte), the receiver will drive the ACK bit as  low logic in timing automatically by the I2C module, it tells transmitter that the transmitter can continue to transfer data.

When the I2C receiver has  received a byte(no matter whether it is an address byte or data byte), the receiver will drive the ACK bit as HIGH logic in timing if the slave receiver set the SLVNACK bit in Slave control register, it tells the master transmitter that the master transmitter can terminate the transfer.

I do not see the Chip_I2CS_SlaveNACK()  function, can you post it here? do you use SDK package?

BR

XiangJun Rong

[_Nathan]

Hi XiangJun,

    The Chip_I2CS_SlaveNACK() function from lpcopen_3_02_lpcxpresso_nxp_lpcxpresso_812.zip

     lpcxpresso812\chip_81x\src\i2cs_8xx.c

https://www.nxp.com/design/microcontrollers-developer-resources/lpcopen-libraries-and-examples/lpcop... 

As the LPC81x User manual, since SLVCONTINUE means "Informs the Slave function to continue to the next operation", SLVNACK means "stop to the next operation'?

[xiangjun_rong]

Hi, Nathan,

Based on I2C protocol, I think that SLVNACK means "stop to the next operation"

BR

XiangJun Rong

[frank_m]

The idea of a monitor device is to not interfere at all.

According to the standard, a device does not physically "respond" with a NACK.

NACK is a passive state, which means either (both) "negative response" or "no response".

Only the ACK signal is actively driven.

I think you will have a difficult time to sue the I2C peripheral if it does not keep "unadressed" transmissions. I never tried that myself.

You might try to configure a USART/UART peripheral to a matching baudrate and 9 bit, and see if you can receive I2C that way.

Bit-banging would always work, but is quite a bit costly in core performance and development time.

[_Nathan]

Hi Frank,

    Thanks. You are right, NACK means "no response".

    The rate of the Master is variable, so it is too difficult to use the UART to monitor I2C data.

[frank_m]

> The rate of the Master is variable, so it is too difficult to use the UART to monitor I2C data.

It should be known or at least detectable at runtime. The standard has limits for each mode (100kBps, 400kBps, 1MBps, ...). But arbitrary lower rates are allowed, this is true.

Detection would be possible by watching a transfer sequence on SCL, and measure the timing with a counter/timer unit. I am not sure how much effort you want to put into your application. But I think it might be less trivial than you expected.

[_Nathan]

In fact, the rate to be monitored is about 50k(or48.9k, 49.5k, 50.1k...) and 100k(or 98k, 99k, 101k...)

For the schedule, maybe I don’t have enough time to implement it.

Is there any example code for this issue?

By the way, I have implemented the monitoring I2C function on STM8 with the help of SPI(NOT UART),but it will take some effort to migrate to LPC812.

[frank_m]

You are right, SPI might be a better alternative. Especially since SPI has a clock input like I2C, so you could skip that step.

As for xiangjun_rong's reply, I am not sure if the I2C peripheral can be used in this case. I have no experience with the LPC812 in this regards.

But my general experience is, such I2C peripheral blocks don't announce data not explicitly addressed to this device.