Using the SPI example to communicate with a CR95HF

RE: Using the SPI example to communicate with a CR95HF

Jørgen Holmefjord — Wed, 23 May 2018 07:30:36 GMT

Please post your question in a new thread. You can link to this question and say it is related, but answering in this thread will make it harder for other users to find the information if they experience similar issues.

RE: Using the SPI example to communicate with a CR95HF

eduardoescarti — Wed, 23 May 2018 06:36:36 GMT

Hi I mistakenly replied to PaulP but maybe you can help me as well :) . Please see bottom most reply. Thanks a lot!

RE: Using the SPI example to communicate with a CR95HF

eduardoescarti — Tue, 22 May 2018 12:23:57 GMT

Hi all! I am having exactly the same issue and don't know how to continue. I have also spend 2 days with this.

I'm using SDK 15.0

My SPI config is as follows:

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;
    spi_config.ss_pin   = NRF_SPI_PIN_NOT_CONNECTED;
    spi_config.miso_pin = SPI_MISO_PIN;
    spi_config.mosi_pin = SPI_MOSI_PIN;
    spi_config.sck_pin  = SPI_SCK_PIN;
    spi_config.orc      = 0xFF;
    spi_config.mode      = NRF_DRV_SPI_MODE_0;
    spi_config.frequency = NRF_DRV_SPI_FREQ_1M;
    spi_config.bit_order = NRF_DRV_SPI_BIT_ORDER_MSB_FIRST;
    
    APP_ERROR_CHECK(nrf_drv_spi_init(&m_spi_master_0, &spi_config, spi_event_handler, NULL));
    
    nrf_gpio_pin_set(IRQ_PIN);
    nrf_gpio_pin_set(SPI_SS_PIN);

   // CR95HF Wake-Up Pulse
   nrf_delay_ms(10);                        // send a wake up
   nrf_gpio_pin_clear(IRQ_PIN);      // pulse to put the
   nrf_delay_us(100);   
   nrf_gpio_pin_set(IRQ_PIN);     // mode
   nrf_delay_ms(10);

I know it might be overkill configuring SS manually but I'm porting code from arduino and it is done like that over there.

The CR95HF SPI works in 3 steps:
1. send command
2. poll with 0x03 until SPI return bit 4 to 1
3. send command 0x02 to read

The corresponding arduino code of step 1 and 2 is:

// step 1 send the command
  digitalWrite(SSPin, LOW);
  SPI.transfer(0x00);  // SPI control byte to send command to CR95HF
  SPI.transfer(0x02);  // Set protocol command
  SPI.transfer(0x02);  // length of data to follow
  SPI.transfer(0x01);  // code for ISO/IEC 15693
  SPI.transfer(0x0D);  // Wait for SOF, 10% modulation, append CRC
  digitalWrite(SSPin, HIGH);
  delay(1);
 
// step 2, poll for data ready

  digitalWrite(SSPin, LOW);
  while(RXBuffer[0] != 8)
    {
    RXBuffer[0] = SPI.transfer(0x03);  // Write 3 until
    RXBuffer[0] = RXBuffer[0] & 0x08;  // bit 3 is set
    }
  digitalWrite(SSPin, HIGH);
  delay(1);

So my ported code looks like this:

uint8_t invcommand[5] = {0x00, 0x02, 0x02, 0x01,0x0D};

nrf_gpio_pin_clear(SPI_SS_PIN);
spi_xfer_done = false;
APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi_master_0, &invcommand, 5, m_rx_buf, 5));
while (!spi_xfer_done)
{
  __WFE();
}
nrf_gpio_pin_set(SPI_SS_PIN);
nrf_delay_ms(1);

nrf_gpio_pin_clear(SPI_SS_PIN);        
while(m_rx_buf[0] != 8) {
  spi_xfer_done = false;
  m_tx_buf[0] = 0x03;
  APP_ERROR_CHECK(nrf_drv_spi_transfer(&m_spi_master_0, m_tx_buf, 1, m_rx_buf, 1));
  while (!spi_xfer_done)
  {
    __WFE();
  }
  
  m_rx_buf[0] = m_rx_buf[0] & 0x08;
}
nrf_gpio_pin_set(SPI_SS_PIN);
nrf_delay_ms(1);

But it never gets out of the STEP 2 while loop and the SPI keeps returning 0x06

I'm hoping to get my hands on a logic analyser and see how the signals on arduino vs DK52 look like.

As for the sdk_config.h SPI data:

NRFX_SPIM_ENABLED 1
NRFX_SPI_ENABLED 1
SPI_ENABLED 1
SPI0_ENABLED 1
SPI0_USE_EASY_DMA 1

RE: Using the SPI example to communicate with a CR95HF

PaulP — Mon, 22 Jan 2018 23:27:16 GMT

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 :)

RE: Using the SPI example to communicate with a CR95HF

Jørgen Holmefjord — Fri, 12 Jan 2018 15:07:47 GMT

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:

RE: Using the SPI example to communicate with a CR95HF

PaulP — Thu, 11 Jan 2018 17:23:44 GMT

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.

RE: Using the SPI example to communicate with a CR95HF

PaulP — Thu, 11 Jan 2018 13:23:49 GMT

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?

RE: Using the SPI example to communicate with a CR95HF

PaulP — Thu, 11 Jan 2018 12:30:44 GMT

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.

RE: Using the SPI example to communicate with a CR95HF

Jørgen Holmefjord — Tue, 09 Jan 2018 14:54:50 GMT

Could you test with this spi_event_handler?

void spi_event_handler(nrf_drv_spi_evt_t const * p_event,
                       void *                    p_context)
{
    spi_xfer_done = true;
    NRF_LOG_INFO("Transfer completed.");
    NRF_LOG_INFO(" Received:");
    NRF_LOG_HEXDUMP_INFO(p_event->data.done.p_rx_buffer, p_event->data.done.rx_length);
}

RE: Using the SPI example to communicate with a CR95HF

PaulP — Mon, 08 Jan 2018 14:10:23 GMT

Yup... had tried before.. I added this tho the event handler (above the if statement)

NRF_LOG_INFO("Not checked>");
NRF_LOG_HEXDUMP_INFO(m_rx_buf, strlen((const char *)m_rx_buf));

My output now looks like this:

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

RE: Using the SPI example to communicate with a CR95HF

Jørgen Holmefjord — Mon, 08 Jan 2018 13:48:30 GMT

Have you tried removing the checking of the first byte in the callback handler (if (m_rx_buf[0] != 0))? You are checking the first byte, but this might actually be 0, as this will depend on what the peripheral clocks out. You seems to be getting multiple transfers where the buffer does not contain 06 in the first byte, but you are not printing the proceding bytes with your code.

RE: Using the SPI example to communicate with a CR95HF

PaulP — Mon, 08 Jan 2018 13:47:39 GMT

Hi Jørgen, Thanks for your answer. I have tried many buffer sizes - I realise the code I quoted ad the wrong value. As you suggest I changed the values - I added this to my declarations:

static const uint8_t m_rx_length = 2;

I changed my spi transfer call to this:

APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &hexdata, m_length, m_rx_buf, m_rx_length));

So my rx buffer size (and m_rx_length) are '2'. This is my output:

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

As you can see.. another 06! and nothing (or 0x00) on subsequent calls... confusion reigns :(

RE: Using the SPI example to communicate with a CR95HF

Jørgen Holmefjord — Mon, 08 Jan 2018 12:28:26 GMT

Hi,

Please have a look at the timing diagrams of the SPI/SPIM peripheral of the nRF52832. When you start a transfer, both TX and RX buffer will be filled on every clocking of the SPI bus. In your code, you have set the length of RX buffer to 1, meaning this buffer will be filled while you transfer the control code to the peripheral (CR95). From the datasheet of CR95, you can see that the response will be sent after the control byte is received. You need to increase the RX buffer to the size of the expected TX+RX bytes, in your test case 2, and ignore the first received byte:

static const uint8_t m_rx_length = m_length + 1;
static uint8_t       m_rx_buf[m_rx_length];
...
void spi_event_handler(nrf_drv_spi_evt_t const * p_event,
                       void *                    p_context)
{
    ...
    if (m_rx_buf[1] != 0)
    ...
}

...
int main(void)
{
    ...
    while (1)
    {
        ...
        memset(m_rx_buf, 0, m_rx_length);
        ...
        APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &hexdata, m_length, m_rx_buf, m_rx_length));
        ...
    }
}

Best regards,

Jørgen