Fatal error in adafruit_pn532_init

[SRall]

Trying to run the experimental nfc pairing reference on a couple of 840 DKs for Bluetooth pairing as it's shipped in SDK 17. 

Successfully compiled the micro-ecc make files for my appropriate boards, and I have the Adafruit PN532 breakout board with headers soldered on it so it will fit the DK (or should I be using the PN532 Adafruit shield specifically?). 

After compiling and flashing the central reference example with no modification, I get a fatal error with no other debug messages. 

After some debugging, I've narrowed it down to the adafruit_pn532_init function and I get this. 

So the error is an NRF_ERROR_INTERNAL, but why no other debug messages from the function? I'm quite confused. 

Here is my main function

int main(void)
{
    NRF_LOG_INFO("Main");
    logs_init();
    NRF_LOG_INFO("logs init");
    timer_init();
    NRF_LOG_INFO("timer init");
    buttons_init();
    NRF_LOG_INFO("buttons init");
    ble_stack_init();
    NRF_LOG_INFO("ble stack init");
    gatt_init();
    NRF_LOG_INFO("gatt init");
    peer_manager_init(false);
    NRF_LOG_INFO("peer manager");
    nfc_init();
    NRF_LOG_INFO("nfc init");
    scan_init();
    NRF_LOG_INFO("scan init");

    NRF_LOG_INFO("NFC Connection Handover BLE Central device example started.");

    while (true)
    {
        if (NRF_LOG_PROCESS() == false)
        {
            nfc_tag_process();
        }
    }
}

And here is the nfc_init function with my debug messages added. 

void nfc_init(void)
{
    NRF_LOG_INFO("NFC INIT FUNCTION");
    ret_code_t err_code = adafruit_pn532_init(false);
    NRF_LOG_INFO("The error code is %d", err_code);
    APP_ERROR_CHECK(err_code);

    nrf_ble_lesc_peer_oob_data_handler_set(nfc_peer_oob_data_get);

    // Register handler for BLE events.
    NRF_SDH_BLE_OBSERVER(m_ble_observer, NFC_BLE_PAIR_OBSERVER_PRIO, ble_nfc_pair_handler, NULL);
}

I get the same results even when setting the <force> argument to true. 

Currently I have SEL0 and SEL1 open on the pn532 breakout, so i2c should be enabled, but I can't tell if this is the problem area. 

Again, I haven't touched the Adafruit PN532 library at all since extracting it fresh from SDK 17. 

All I want to do is get a my two 840 DKs to pair over NFC.

Any help would be appreciated!

Thanks!

Sam

[SRall]

UPDATE:

After some more debugging, I've found that the adafruit_pn532_cmd_send is kicking back the NRF_ERROR_INTERNAL because it seems that adafruit_pn532_waitready_ms function evaluates to false every time. Still not sure why this is happening or how I can fix it... assistance would be much appreciated. 

[Kenneth]

Is there a logic analyzer trace available for the twi data? Have you placed pull-up resistors on the twi pins? Have you tried running the twi scanner example in the nRF5 SDK to verify that twi is able to connect to the reader (and at the same time verify the twi address)?

[SRall]

All I have is the Adafruit NFC board mounted on the DK per the Arduino standard headers, which is all it should take to function. I ran the twi scanner and confirmed it finds the reader at 0x24. 

[Kenneth]

I don't have any good suggestion here than to double check that all connections are good (e.g. twi sda and scl, irq and reset), you may need a logic analyzer for this. Just pointing to the documentation:

https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/lib_adafruit.html 
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/nfc_adafruit_with_tag_parser.html 

I have tried to go through previous cases for similar issue, like the one below, but I can't find anyone with exactly the same issue:

https://devzone.nordicsemi.com/f/nordic-q-a/55798/pca10056-version-of-adafruit_tag_reader-example-ends-with-err_code-0x03 

Hopefully a logic analyzer trace and some trial and error will make it work. You may try a different nRF5 SDK in case there is something failing in the latest (thought I doubt that is the case).

[SRall]

Did you look at the code at all? I've done a fair amount of debugging here and have narrowed down the exact function that is tripping this error... care to comment on why that's happening? Perhaps another engineer could have a look?