This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Fatal error in adafruit_pn532_init

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

Parents
  • 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. 

  • 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)?

  • As I've already said, the Adafruit PN532 breakout is mounted to the DK via the Arduino standard headers. This makes IRQ connected to P1.03 and I have wired the RST to P1.01 which I have correctly configured here. 

    Yes it fails on the first iteration. 

  • I looked at the implementation in code:

    bool adafruit_pn532_is_ready(void)
    {
        return nrf_gpio_pin_read(m_pn532_object.irq) == 0;
    }

    In other words it is waiting for irq to go low.

    Looking at the user manual I can find in chapter 6.3.3 the handshaking mechanism:
    https://www.nxp.com/docs/en/user-guide/141520.pdf

    It looks like (from 6.3.3.3) the PN532 should set IRQ high when it recognize it's I2C slave address (and from your trace it does), however the PN532 should assert the IRQ line again as soon as it is ready to send back data (but that doesn't seem to occur in your case).

    I think you may need to look at your module, it could be other pins not directly related to the handshaking signals that are not correct.

  • Looking at your trace again, I can see that there is actually a second read started here after the stop bit after the first transaction. That read should not occur until irq go low. 

    Can it be a timing issue here of some kind. Can you for test try to add a 100us delay in adafruit_pn532_cmd_send() after adafruit_pn532_command_write() before calling adafruit_pn532_waitready_ms()?

    Edit: The intention of the 100us delay is to ensure that the polling of adafruit_pn532_waitready_ms() does not start before irq go high after the twi address is sent.

    Edit2:

  • Thanks Kenneth, I did add the delay that you suggested with no change to the error output I was getting. However, it seems the Adafruit team might have mixed up their documentation on how exactly the SEL jumpers should be configured for I2C - there's conflicting documentation that says both SEL1+0 = open, and other places it says SEL0 should be closed. I've posted to their forums as well. Thank you for the assistance here, I will keep this thread updated. 

  • Sounds good, but I recommend to try to check what may be causing that second read here. I expect that the library is first calling nrf_drv_twi_tx() to write the command, then it should be waiting for irq go low before calling nrfx_twi_rx() to fetch the ack. It could be interesting if you set a breakpoint in nrfx_twi_rx() to check if it's being called, and from where it is being called.

Reply
  • Sounds good, but I recommend to try to check what may be causing that second read here. I expect that the library is first calling nrf_drv_twi_tx() to write the command, then it should be waiting for irq go low before calling nrfx_twi_rx() to fetch the ack. It could be interesting if you set a breakpoint in nrfx_twi_rx() to check if it's being called, and from where it is being called.

Children
No Data
Related