Trouble using TI CC2650 to communicate with PN532 on I2C at 100khz

DaleKramer · ‎12-30-2020

I have been able to get a successful response to a GetFirmwareVersion request using an Arduino Nano on from this ElecHouse NFC Module V3 (PN532):

But, I can not get a successful response to a GetFirmwareVersion request using a TI CC2650 processor.

Here is my current summary as to where I think things start to go wrong:

There seems to be a mystery pulse in the CC2650 as Master data stream and I can not figure whether the PN532 is generating it or the CC2650, whether this mystery pulse is the reason that the PN532 stops listening after the pulse with the CC2650 as Master and whether the mystery pulse is responsible for the HUGE clock stretching that occurs with the CC2650 as Master.

Any ideas?

You can get further background here in my TI forum topic.

Please provide any helpful suggestions to help solve my problem.

Thanks,

Dale Kramer

DaleKramer · ‎12-31-2020

MORE INFO:

Both the CC2650 and the PN532 pull the I2C lines to a different LOW voltage level. The PN532 pulls low to ~0.2v (due to 2N7002 mosfet drivers on the PN532 module board) and the CC2650 only pulls lows down to 0.7v.
After the 8th clock cycle from the CC2650 when it has sent the PN532 slave address, the PN532 sends an ACK on the data line and is confirmed by the fact that the data line is pulled down to ~0.2v about 0.4us after the clock line reaches a low value after the 8th clock bit.
The CC2650 then provides a 9th clock cycle before the PN532 starts to clock stretch at about 1us after the clock line reaches a low value after the 9th clock bit (you can see the clock stretching initiated by the PN532 since it brings the clock line down to ~0.2v at that point.
Now along comes the 0.2us wide mystery pulse on the data line about 0.4us after the 9th clock bit is brought low by the CC2650, but who created it?.
BOTH the CC2650 and the PN532 must have simultaneously released the data line but I think someone should have held it low since the next data bit that the CC2650 will send after the clock stretching is 0 (from 0x00).

Here is a zoomed in view of the 8th and 9th clock bits and the 2us wide mystery data pulse:

Who should have held the data line low during the clock stretching, the CC2650 Master in anticipation of sending a low bit after the stretch or the clock stretching PN532 slave?

Is this mystery data pulse what is causing the PN532 to stop acknowledging the data from the Master after the clock stretching is finished?

DaleKramer · ‎01-02-2021

MORE INFO:

I have pretty confidently determined that the mystery pulse is not the reason that the PN532 does not ACK after the first data byte sent from the CC2650 after the PN532 finishes clock stretching.

The only difference in bus traffic other than the mystery pulse is that the PN532 stretches the CLK 6ms when connected to the CC2650 I2C bus while it only stretches the CLK by 0.5ms when connected to the Arduino I2C bus.

Does anyone know under what conditions that the PN532 clock stretches for 6ms?

Kan_Li · ‎01-06-2021

Hi @DaleKramer ,

PN532 is a slave device during I2C communication, and it just drives the SDA line during ACK stage, if the main change is switching the host controller, the root cause is most likely on the controller side.

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

DaleKramer · ‎01-06-2021

But isn't the PN532 responsible and in full control of the clock stretching after it ACKs it's slave address so why would it clock stretch for 6ms (after which it does not ACK the next data byte) in one case and 0.5ms (after which it does ACK the next data byte) in the other case?

Kan_Li · ‎01-08-2021

Hi @DaleKramer ,

For clock stretching , it is related with SCL line, but your issue is the pulse on SDA line, and referring to your zoomed view, the 9th bit has a low voltage on SDA line(yellow), it is the ACK bit sent from PN532, as you mentioned before, PN532 can pull down to 0.2 v or so but TI CC2650 just down to 0.7V, you may find this ACK bit 's voltage level is lower than the previous bits driven by TI CC2650, but after that, the SDA line must be pulled down by CC2650 as the voltage level is higher than ACK bit's level, it should be at 0.7V or so.

Hope that makes sense,

Have a great day,
Kan

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

DaleKramer · ‎01-08-2021

Here are the same bits without pullups on the CC2640 showing the Lows pulled down to 360 mv which should be within all Low standards, unfortunately the LONG 6ms clock stretch still happens and the PN532 still does not ACK after the first data bit is sent from the CC2640 after the clock stretch:

Here is what the gurus at the TI form comment:

The CC2640 lets "go after the 8th clock bit so that the PN532 could ACK on the 9th, and only regains control after the observed pulse. As stated previously the delay in doing so should be inconsequential given the status of the SCL line and I2C protocol. I suspect the same behavior is evident in the working BME280. You can ask the NXP forum as to why this may be a concern for the PN532."
"In regards to the pulse on the SDA line, I agree that both the master and slave have released it after the slave ACK and before the master regains control. During this time neither controls the line and it's pulled high by the mandatory pull-up resistors. This is perfectly fine as the SCL line is low and SDA is only sampled when SCL is high. This should not affect I2C communication according to the protocol and I don't know why the PN532 logic would be concerned over this."

From my perspective, I wonder why the PN532 does the LONG 6ms clock stretch.

And also, why would the short data pulse even be noticed by the PN532 during its clock stretching since the data line should not be read while the clock is low?

Thanks for your help on this.

DaleKramer · ‎01-08-2021

Here is the 9th pulse with no pullup resistors on the TI CC2640, it is now pulling a Low to 360mv which should be fine by all standards:

And the LONG 6ms clock stretch persists, and PN532 does not ACK the next data bit from the CC2640.

From the gurus at the TI forum:

The CC2640 lets go "after the 8th clock bit so that the PN532 could ACK on the 9th, and only regains control after the observed pulse. As stated previously the delay in doing so should be inconsequential given the status of the SCL line and I2C protocol. I suspect the same behavior is evident in the working BME280. You can ask the NXP forum as to why this may be a concern for the PN532. You could also consider further optimizing the pull-up resistance to address the pull-down voltage level difference."
"In regards to the pulse on the SDA line, I agree that both the master and slave have released it after the slave ACK and before the master regains control. During this time neither controls the line and it's pulled high by the mandatory pull-up resistors. This is perfectly fine as the SCL line is low and SDA is only sampled when SCL is high. This should not affect I2C communication according to the protocol and I don't know why the PN532 logic would be concerned over this."

From my view, why does this narrow pulse make the PN532 clock stretch for so long and fail to Ack the next data bit after the clock stretching?

From what I understand, pulses on the data line should not be of any consequence either master or slaves since the data line should only be read when the clock is high?

Thanks for your help here.