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
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?
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.
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.
