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

Using the SPI example to communicate with a CR95HF

Good evening all, I'm trying to get my DK52 communicating with a CR95HF (this is a NFC controller with serial and SPI control interfaces), I'm using a breakout board - BM019
The CR95 requires a setup sequence to select the SPI interface image description

So far I'm using the SPI example from SDK 14, I have modified it to toggle the IRQ_IN pin I'm using pin30) on initialization, I then attempt to send 0x55 to the CR95 (this is a Echo command - I'm expecting 0x55 back). However I seem to get back 0x06 (the first two loops) then nothing for any additional requests)

I have tried removing my initialization toggle, when I do this I don't get anything back on any of the loops)

Here's my modified code.

#define SPI_INSTANCE  0
static const nrf_drv_spi_t spi = NRF_DRV_SPI_INSTANCE(SPI_INSTANCE);  
static volatile bool spi_xfer_done; 

//#define TEST_STRING "Nordic"
//static uint8_t       m_tx_buf[] = TEST_STRING;      
static uint8_t       m_rx_buf[2];  //sizeof(TEST_STRING) + 1];   
static const uint8_t m_length = 1; //sizeof(m_tx_buf);        

void spi_event_handler(nrf_drv_spi_evt_t const * p_event,
                       void *                    p_context)
{
    spi_xfer_done = true;
    NRF_LOG_INFO("Transfer completed.");
    if (m_rx_buf[0] != 0)
    {
        NRF_LOG_INFO(" Received:");
        NRF_LOG_HEXDUMP_INFO(m_rx_buf, strlen((const char *)m_rx_buf));
    }
}

uint8_t hexdata = 0x55;

int main(void)
{
    bsp_board_leds_init();

    APP_ERROR_CHECK(NRF_LOG_INIT(NULL));
    NRF_LOG_DEFAULT_BACKENDS_INIT();
    nrf_gpio_cfg_output(30);
    nrf_gpio_cfg_output(29);
    nrf_gpio_pin_set(30);
    nrf_delay_ms(3000);
    NRF_LOG_INFO("SPI example.");

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.ss_pin   = SPI_SS_PIN;
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
    
   nrf_gpio_pin_clear(30);
    nrf_delay_us(100) ;        // BM019 into SPI
    nrf_gpio_pin_set(30);
    nrf_delay_ms(10) ;
    APP_ERROR_CHECK(nrf_drv_spi_init(&spi, &spi_config, spi_event_handler, NULL));
    nrf_delay_ms(1000);
    
    while (1)
    {
        // Reset rx buffer and transfer done flag
        memset(m_rx_buf, 0, m_length);
        spi_xfer_done = false;
        APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &hexdata, m_length, m_rx_buf, m_length));
        while (!spi_xfer_done)
        {
            __WFE();
        }

        NRF_LOG_FLUSH();

        bsp_board_led_invert(BSP_BOARD_LED_0);
        nrf_delay_ms(1000);
    }
}

and my output.

<info> app: SPI example.
<info> app: Transfer completed.
<info> app:  Received:
<info> app:  06                     |.       
<info> app: Transfer completed.
<info> app:  Received:
<info> app:  06                     |.       
<info> app: Transfer completed.
<info> app: Transfer completed.
<info> app: Transfer completed.
<info> app: Transfer completed.

I have tried so many thing I'm starting to lose my mind on what I've done! (2 days now!!!) I think i'm initializing it but not 100% sure. I get that this might be a bit out of scope on the Nordic site but I'm thinking this is more a SDK issue!

  • Hi Jørgen,

    Thanks for your continued support!

    I was making no progress so decided to take a step back for a few days.

    When re investigating I put together a test using a AVR and Arduino code, It worked reading data from a Tag, So I tried the Echo command in Arduino - it Failed! At this point I decided to try a more complicated command on the nFR (Set Protocol)... It worked!!! However sadly the next command failed (doing inventory). I then tried the IDN command (it should return basic information about the CR95) - it sorta worked! - for example it returns:

    "00 0F" "00 00 00 00 00 00 00 00 03 06 07 07 03" 06 00
    

    And not something more like: (per the data sheet)

    "00 0F" 4E 46 43 20 46 53 32 4A 41 53 54 34 00" 2A CE
    

    Above you can see the first two bytes seem OK cmd-result and length of data returned. Then the next 13 Bytes should be some ASCII text (it's not - mostly zeros) then the checksum.. could be correct I don't know!

    So very strange results - unless you have any more suggestions I think I'll try and find some ST help :(

    Thanks again for your support.

  • Sometimes when chasing a fault you end up down the wrong path... but..

    I was staring at the terminal window of crap data and noticed that all the first nibbles returned where zero, then I realised that the commands that have worked have all only required 0's in the first nibbles (of each byte). I don't know what if anything this means, I have tried different SPI modes before... but I will try them again later, but can you think of any other reason for this... or am I just making things up now?

  • Changing modes made no difference - modes 0 and 3 worked the same, I read that both these modes are supported can't find where tho, (I have it in mode 0). Modes 1 and 2 gave even more random results.... still with all zeros in the first half of each byte.

  • From the BM019 datasheet: The SPI operates using Mode 0: clock is idle low and data shifted on the falling edge. From the CR95 datasheet, the SPI protocol expects a control byte at the start of every transfer. When sending a command, this seems to be 0x00:

    image description

  • Hi, I thought I should come back and close this off!

    So after much faffing around I finally got the thing working! As expected user error was the major cause of issues.

    #1) User error - I misunderstood the data sheet - it said that the echo command only had one bit (0x55), that's true, but you also need the control byte (0x00), then poll for answer as all other commands.

    #2) More user error - general messing about with things whilst fault finding.

    #3) ...Probably more user error, but changing the character used to clock stuff out of the CR95HF via SPI from 0xFF to 0x00 fixed 99% of the issues.

    Thanks again for your support :)

Related