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

[Karl Ylvisaker]

Hello Sam,

Sam_Rall said:

I'll keep working on it but again, a bit at the end of my rope on this. 

I understand - it is indeed very frustrating when things does not work as expected, with no clear cut reasoning or fix.
I am however confident that we together will be able to resolve this issue!

Sam_Rall said:

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.

Great, I am happy to rule out this possibility as well.
Lastly, could you walk me through what changes you made to migrate the example from the nRF52832 ( as it is provided, for the nRF52 DK ) to the nRF52840 that you are working with? I would like to rule out these changes as a potential issue as well.
Based on the logical analyzer screenshot you shared earlier and the test using the twi_slave example ( which got an acknowledgement on an address ) we know that it is connected correctly.

Sam_Rall said:

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?

If someone had developed this driver privately, then this would also have been my go-to suspicion, but since it is a credited driver with a seemingly glaring issue, I would not think that this would be the case. From the descriptions and images you have shared, it seems that the initial command - get firmware version - is sent and acknowledged successfully. It is the waiting for the response containing the firmware version that is timing out.
So, we know that there is communication between the devices - it is just not flowing as expected.

Sam_Rall said:

Is there any way I can retrieve  info from the I2C registers to see what might be happening when the NACK is received?

Just to check, could you try to comment out line 263 through 273 of the adafruit_pn532.c? This section only attempts to retrieve the firmware version of the PN532, to confirm that it is connected and responding as intended.
Removing this section and running the example again will confirm that the issue is not limited to this particular command ( if it fails in a similar way when it gets to the sam_config function.
If you could provide the logger output and/or logical traces for this test, that would be very helpful for me to have a look at.

Looking forward to resolving this issue together!

Best regards,
Karl

[SRall]

Karl Ylvisaker said:

Lastly, could you walk me through what changes you made to migrate the example from the nRF52832 ( as it is provided, for the nRF52 DK ) to the nRF52840 that you are working with? I would like to rule out these changes as a potential issue as well.

In the beginning, I did think it was a pinning issue because the sdk_config has the PN532_IRQ set to pin 13, which didn't make sense to me at first. But after some tinkering with different pinning configs, it didn't seem to matter and was still getting errors.

After that I simply stuck to erasing the DK completely and flashing s132 plus the ble_nfc_paring_reference_c example with the PCA10040 support (as this is the only support it ships with) from a fresh extracted SDK 17. I'm aware the 840 DK has the PCA10056 but again I thought I was ok on the backward compatibility. I've literally made no other changes apart from enabling DEBUG options and other changes per your instructions as I post results. 

Karl Ylvisaker said:

Just to check, could you try to comment out line 263 through 273 of the adafruit_pn532.c? This section only attempts to retrieve the firmware version of the PN532, to confirm that it is connected and responding as intended.

Unfortunately it seems the SAM config command (or any command) indeed times out as well. 

Although I did  notice the IRQ dropping a few hundred uS after the command is sent, but only on every OTHER system reset cycle. Every other cycle the IRQ still refuses to come down at all. 

Not sure if this was helpful, not wanting a goose chase here but it seemed odd. 

Cheers,

Sam

[SRall]

UPDATE: Big breakthrough here. 

Out of curiosity I flashed the adafruit_tag_reader example from SDK 17 and the PN532 communicates effectively with the 840. I can see the waitready_ms() function operate properly because the IRQ comes down about 225uS (the delta between my red cursors below) after a command is sent and the ACK is actually picked up.

 

So the important discovery here is that the PCA10040 support for this example is where I was going wrong because the adafruit_tag_reader example will only function properly on my 840 DK with the PCA10056 supported example. When I flashed the adafruit_tag_rader example with the 10040 support, I got identical errors as we've been discussing. So I'm afraid I must take some responsibility in not knowing that this was actually more of a hardware selection issue. I wasn't aware the difference in board support could cause issues such as this, I've run plenty of Nordic SDK examples with different boards (for testing only, not production) and have had no major issues such as this. Big whoops on my part. 

SO

Taking a look at pca10056.h, I can see the pinouts are completely different for PN532_IRQ and PN532_RESET. However, whenever I try and incorporate the appropriate changes into the ble_nfc_pairing_reference_c by studying the differences in the board support, I still can't get the example to run properly on the 840. Instead of NRF_ERROR_INTERNAL I get crazy error values that output as "Unknown Error".

So I'm still a little bit in need of some help. I will spend today researching how to migrate this board support, as there's still no PCA10056 support for ble_nfc_pairing_reference_c that I can find - unless you know where I could look? Hoping this example is still possible on the 840? My application MUST use the 840 silicon, I cannot drop down to the 832. 

Eternally wishing I would have discovered this sooner,

Cheers,

Sam

[SRall]

PROGRESS: After sifting through the sdk_configs of both the 10040 ble_nfc_pair_reference example as well as the adafruit_tag_reader for 10056, I implemented a new sdk_config for a PCA10056 example of the ble_nfc_pairing_reference.

6864.sdk_config.h

Modifications include the correct pinout for the 840 DK and enabling/adding the necessary modules and backends. This does compile for me but please take a look to see if I'm missing something. Additionally I made sure to add pca10056.h to the project and update the preprocessor defs to reflect the hardware and Soft Device 140 (I also erased s132 and flashed s140 to the DK).

Furthermore, I was able to get the 840 to successfully pick up the ACK from the PN532 by adding a 1ms delay to the adafruit_pn532_ack_read.

Although I can observe the program does indeed move on from the waitready_ms and the cmd_send function that we've been discussing, I seem to be getting a brand new issue that may require a completely different ticket. I'm still stuck in the adafruit_pn532_init because no matter what command is sent to the PN532, it simply dumps 0x80808080808080 as its response (despite the ACK after the command). 

SO

Back to not knowing what the heck is going on at all anymore. I'd be happy to create another ticket since this seems to be moving on from my earlier issue. Unless you can tell where I might be going wrong?

Cheers,

Sam

UPDATE: I went back to the s132 and the PCA10040 supported example for the nfc pairing. 

1. Extract fresh SDK 17
2. Compile micro-ecc libraries
3. Erase DK
4. Flash S132
5. Modify PN532_IRQ and PN532_RESET to pin 35 and 36, respectively in the sdk_config. 
6. Add 1ms delay to adafruit_pn532_ack_read as pasted above.
7. Flash the PCA10040 supported example in Segger Embedded Studio. 

Result it the ACK is successfully picked but the PN532 continues to dump 0x80 continuously as its response to ANY command. I've tried commenting out the Get-Firmware command, but the SAM config command still gets 0x80 as a response data, which is incorrect and causing an error.

[Karl Ylvisaker]

Hello Sam,

Sorry for my late reply, I have been out of office for some days.

I am happy to see your many updates on this - It seems that you have had quite some breakthroughs!

Sam_Rall said:

After that I simply stuck to erasing the DK completely and flashing s132 plus the ble_nfc_paring_reference_c example with the PCA10040 support (as this is the only support it ships with) from a fresh extracted SDK 17. I'm aware the 840 DK has the PCA10056 but again I thought I was ok on the backward compatibility. I've literally made no other changes apart from enabling DEBUG options and other changes per your instructions as I post results. 

This is unfortunately not entirely correct, as you seem to have concluded on your own also. There is some porting/configuration necessary to make an example for the PCa10040 run on the PCA10056 and visa versa. I will get back to this later in my reply.

Sam_Rall said:

So the important discovery here is that the PCA10040 support for this example is where I was going wrong because the adafruit_tag_reader example will only function properly on my 840 DK with the PCA10056 supported example. When I flashed the adafruit_tag_rader example with the 10040 support, I got identical errors as we've been discussing. So I'm afraid I must take some responsibility in not knowing that this was actually more of a hardware selection issue.

This is great debugging on your part, and I believe your conclusion about the root cause to be correct.
I too must take some responsibility here, because I assumed that you were aware of this difference, my apologies.

Sam_Rall said:

So I'm still a little bit in need of some help. I will spend today researching how to migrate this board support, as there's still no PCA10056 support for ble_nfc_pairing_reference_c that I can find - unless you know where I could look? Hoping this example is still possible on the 840? My application MUST use the 840 silicon, I cannot drop down to the 832. 

There is indeed no support for this example on the PCA10056, unfortunately.
However, fortunately, it should be pretty straight forward to port, and indeed absolutely possible on the 840 silicon.

Sam_Rall said:

After sifting through the sdk_configs of both the 10040 ble_nfc_pair_reference example as well as the adafruit_tag_reader for 10056, I implemented a new sdk_config for a PCA10056 example of the ble_nfc_pairing_reference.

Did you do this manually? If you are developing on Linux, you should do this using the "diff" command, to easily see the difference between two files.
If you are using windows I suppose you could do the same using some variation of a PowerShell command.

Sam_Rall said:

Modifications include the correct pinout for the 840 DK and enabling/adding the necessary modules and backends. This does compile for me but please take a look to see if I'm missing something. Additionally I made sure to add pca10056.h to the project and update the preprocessor defs to reflect the hardware and Soft Device 140 (I also erased s132 and flashed s140 to the DK).

APP_TIMER_V2
APP_TIMER_V2_RTC1_ENABLED
BOARD_PCA10056
CONFIG_GPIO_AS_PINRESET
DEBUG
FLOAT_ABI_HARD
INITIALIZE_USER_SECTIONS
NO_VTOR_CONFIG
NRF52840_XXAA
NRF_SD_BLE_API_VERSION = 7
S140
SOFTDEVICE_PRESENT

//linker flash placement macros:
FLASH_PH_START = 0x100000
RAM_PH_SIZE = 0x40000
FLASH_START = 0x27000
FLASH_SIZE = 0xd9000
RAM_START = 0x20002260
RAM_SIZE = 0x3dda0

You could reference the above for what you will need to change in the project settings.
You'll also need to change some user included directories, to point from /modules/nrfx/mdk/ses_startip_nrf52 to /modules/nrfx/mdk/ses_startup_nrf52840, for example.

Sam_Rall said:

Furthermore, I was able to get the 840 to successfully pick up the ACK from the PN532 by adding a 1ms delay to the adafruit_pn532_ack_read.

Great to hear that you got it to work! It sounds strange to me that you need to insert a 1 ms delay to get it to work, however.
What happens if you do not have the 1 ms delay in place? Is there an error generated, or is it the same behavior as we have seen before with the IRQ staying high?

Sam_Rall said:

I'm still stuck in the adafruit_pn532_init because no matter what command is sent to the PN532, it simply dumps 0x80808080808080 as its response (despite the ACK after the command). 

Sam_Rall said:

Result it the ACK is successfully picked but the PN532 continues to dump 0x80 continuously as its response to ANY command. I've tried commenting out the Get-Firmware command, but the SAM config command still gets 0x80 as a response data, which is incorrect and causing an error.

This seems like a new error indeed, but I cant help but think it could be related to the previous issues somehow..
When you tested this with the adafruit_tag_reader example, did everything work as intended then? Did the board respond anything else than 0x8080808080?

Sam_Rall said:

I'd be happy to create another ticket since this seems to be moving on from my earlier issue. Unless you can tell where I might be going wrong?

Let us stick to this ticket a little longer, then maybe we'll create a separate new one for this particular issue if we do not resolve it very soon.

Looking forward to getting to the bottom of the weird output. I'll ask those of my colleagues who have worked with the PN532 if they have seen similar behavior.

Best regards,
Karl