nrf_drv_twi_tx & rx with Adafruit PN532

[SRall]

I have the Adafruit PN532 Shield v1.3 mounted to an nRF52840 DK, trying to run the ble_nfc_pairing_reference_c example from SDK 17. With no modification to the example code, I was getting the following output.

 

After some debugging I found the error was returning from the nrf_drv_twi_tx function with these default arguments passed. 

To investigate, I flashed the twi_scanner example and successfully found the PN532 at address 0x24. 

Since this doesn't match the PN532_I2C_ADDRESS being passed in the nfc reference example, I changed (0x48 >> 1) to (0x24). This resulted in the following output. 

The only difference being that the tx function seemed to send data successfully, but the nrf_drv_twi_rx function that passes those same parameters was returning a wild error while trying to read the acknowledgement. 

Since I was getting two different error scenarios, I re-extracted a fresh SDK 17 and tried again, but the exact behavior occurred. Does anyone know what is going on here?

My theory is that either there is something wrong with the Adafruit hardware, or these parameters are not configured correctly, unless I'm missing something. 

Any help here would be much appreciated. 

Thanks in advance!

Sam

[SRall]

https://www.nxp.com/docs/en/nxp/data-sheets/PN532_C1.pdf

Here is the data sheet for the PN532, I'll take today to look through the I2C documentation and configuration.

However, if I'm following the instructions per the Nordic SDK documentation for this NFC ref example, it should really work without much tinkering if I'm not changing anything in the code... either that or your SDK documentation should be updated to say that this example doesn't work in all cases. Indeed, it does not seem like this pn532 library was written correctly if I can't simply compile and run this example with fresh hardware out of the box. Please, if you are able, look into replicating this example and see if you experience any similar issues. 

[Karl Ylvisaker]

Hello again Sam,

Sorry for my late reply.

Sam_Rall said:

Here is the data sheet for the PN532, I'll take today to look through the I2C documentation and configuration.

 Thank you. I just needed to confirm that we were on the same page here.

Sam_Rall said:

However, if I'm following the instructions per the Nordic SDK documentation for this NFC ref example, it should really work without much tinkering if I'm not changing anything in the code...

Agreed, absolutely. I will reach out to the developers of this example to get their feedback on this. There should not be any need for modifications to get this up and running as per the documentations setup and testing section. I must however also emphesize that this particular example is still tagged as experimental, but it should of course work out-of-the-box regardless of this. After all, it has gone through rigorous testing before being added to the SDK release.

Just to summarize; you are following the setup and testing documentation for the Experimental: BLE Pairing Using NFC - Central Reference Example from the nRF5 SDK v.17.0.2, and it seems that the IRQ of the PN532 never goes low again after the first transfer, indicating that the PN532 is not ready for the following rx transfer. As I understand it, this issue becomes apparent when the device is powering on - without needing any input (such as button presses) from you, correct?
Could you check how many times the loop in adafruit_pn532_waitready_ms is executed, and confirm that it moves on from the loop as a result of the 'timeout'?

Could you confirm for me which SoftDevice and version you have flashed your device with, prior to flashing the example?
Could you also confirm that you have installed the micro-ecc library successfully?
How did you program the device, using nRF Connect Programmer, or nrfjprog from the command line?

Sam_Rall said:

Please, if you are able, look into replicating this example and see if you experience any similar issues. 

If there is no immediate note on this by the developers I will indeed try to replicate this on my end, and see if I can not get to the bottom of why it is unable to contact the board.

Looking forward to resolving this together!

Best regards,
Karl

[SRall]

Karl Ylvisaker said:

As I understand it, this issue becomes apparent when the device is powering on - without needing any input (such as button presses) from you, correct?

That is correct, yes.

Karl Ylvisaker said:

Could you check how many times the loop in adafruit_pn532_waitready_ms is executed, and confirm that it moves on from the loop as a result of the 'timeout'?

Looking at the waitready_ms function closer, it seems to get called each time with a 1000 (1 second) value passed to it, and indeed it does exit the loop having timed out of this value. 

As you can see above, I've stopped the debugger after it exits the loop, RESULT is still false, and TIMER equals TIMEOUT of 1000. Note my debug message on line 893 and the corresponding output below which confirms this. 

Karl Ylvisaker said:

Could you confirm for me which SoftDevice and version you have flashed your device with, prior to flashing the example?

I believe I had flashed s140 to this 840 DK a while ago before flashing this nfc example (as I need long range capability for our product application). Am I correct in assuming this is ok because s140 is backward compatible? Hopefully this wasn't my mistake?

Karl Ylvisaker said:

Could you also confirm that you have installed the micro-ecc library successfully?

 Yes I have followed the instructions for installing the micro-ecc library successfully per the SDK doc page you linked above. Also, the example won't compile without it?

Karl Ylvisaker said:

How did you program the device, using nRF Connect Programmer, or nrfjprog from the command line?

Flashing directly to the device with Segger Embedded Studio and the JLink. Not sure what backend is needed for that off the top of my head but I know this computer has both. 

Again, can't thank you enough for the assistance here!

Let me know if there's more info you need. 

Sam

[Karl Ylvisaker]

Hello Sam,

Sam_Rall said:

Looking at the waitready_ms function closer, it seems to get called each time with a 1000 (1 second) value passed to it, and indeed it does exit the loop having timed out of this value. 

Great, thank you for confirming this. This is in line with what was shown in the logic analyzer output you showed earlier - the PN532 never pulls the IRQ low again after the first transmission series, to indicate that it is ready again. This currently looks to be the point of failure for the example, so we should look into the possible reasons for why the PN532 would behave like this.

Sam_Rall said:

I believe I had flashed s140 to this 840 DK a while ago before flashing this nfc example (as I need long range capability for our product application). Am I correct in assuming this is ok because s140 is backward compatible? Hopefully this wasn't my mistake?

I see, thank you for clarifying.
Could I ask you to try this example again, with the S132, to see if there is any difference in the behavior then? The example's documentation notes this as the only SoftDevice that it is made for and tested with.
It should well be possible to modify the example to work with the S140, but we will first need to rule out that this could be the source of the error. While initially it might seem unrelated to the high IRQ line, I would like to rule the SoftDevice out as a possibility before we proceed with other options.

Sam_Rall said:

 Yes I have followed the instructions for installing the micro-ecc library successfully per the SDK doc page you linked above. Also, the example won't compile without it?

Yes, I just wanted to make sure that everything had run smoothly up until the running application, thank you for letting me know.

Sam_Rall said:

Again, can't thank you enough for the assistance here!

It is no problem at all, Sam, I am happy to help!

Looking forward to getting to the bottom of this issue!

Best regards,
Karl

[SRall]

Karl Ylvisaker said:

Could I ask you to try this example again, with the S132, to see if there is any difference in the behavior then? The example's documentation notes this as the only SoftDevice that it is made for and tested with.

Yeah over the weekend I did give this some more time debugging and tinkering, and it's safe to safe to say the SoftDevice is not the issue here. I flashed s132 from a clean SDK 17 as well as the example and there was no change in behavior whatsoever. I will continue to keep the s132 on the DK until this gets resolved before adapting to the s140.

I've also been pouring over the data sheet as well, searching for a reason the IRQ pin is not being set to 0 when it should be. I'm not sure where in the firmware these sections would apply, but could it be possible the I2C configuration is not setup for interrupt requests? I've attached some clips of the datasheet I feel are relevant here but honestly it's sort of a last ditch effort.

Has there been any word from the developers of the adafruit_pn532 library? Is there any way I can retrieve  info from the I2C registers to see what might be happening when the NACK is received? Pages 58-63 of the datasheet contain I2C transmitter status codes with scenarios and descriptions, I'll keep working on it but again, a bit at the end of my rope on this. 

Cheers,

Sam