Skip to main content
Visitor II
July 25, 2018
Solved

Communication with CR95HF does not work.

  • July 25, 2018
  • 1 reply
  • 822 views

i try to use the nfc reader cr95hf (MIKROE-143) since a few days. as mcu i use the evaluation board nRF52832. unfortunately i don't succeed so far.

The data sheet for the MIKROE-143 can be found here:

https://www.mouser.ch/datasheet/2/272/rfid_click_manual-255532.pdf

I use SPI as communication interface (I set SSI_0 high and SSI_1 low.). According to their datasheet, the CR95HF SPI works in 3 steps:

1. send command

2. poll with 0x03 until SPI return bit 3 to 1

3. send command 0x02 to read

A Control byte is used to specify a communication type and direction:

  • 0x00: Send command to the CR95HF
  • 0x03: Poll the CR95HF
  • 0x02: Read data from the CR95HF
  • 0x01: Reset the CR95HF
  • The SPI_SS line is used to select a device on the common SPI bus. The SPI_SS pin is active low.

My SPI configuration looks like this:

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.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(&spi, &spi_config, spi_event_handler, NULL));

The following steps are taken from this data sheet:

http://www.solutions-cubed.com/content/Downloads/Breakout%20Modules/DATASHEET_BM019.pdf

step 1, send the command:

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

step 2, poll for data ready:

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

step 3, read the data:

nrf_gpio_pin_clear(SPI_SS_PIN); 
spi_xfer_done = false;
APP_ERROR_CHECK(nrf_drv_spi_transfer(&spi, &readcommand, 1, read_buff, sizeof(read_buff)));
while (!spi_xfer_done){__WFE();}
nrf_gpio_pin_set(SPI_SS_PIN);
nrf_delay_ms(1);

variable:

uint8_t sendrecv[6] = {0x04, 0x03, 0x26, 0x01, 0x00};
uint8_t invcommand[5] = {0x00, 0x02, 0x02, 0x01,0x21};
uint8_t pollcommand = 0x03;
uint8_t readcommand = 0x02;
uint8_t control_command = 0x00;

after step 1:

0690X0000060NtfQAE.png

after step 2:

0690X0000060NtkQAE.png

after step 3:

0690X0000060NtpQAE.png

where does this strange response come from (0x0E 0x00 0x00 0x00 0x00 0x00 0x00 0x00.... 0x00 0x00 0x00 0x00)?

why do i get 0x0E so often?

i kept the startup routine. i checked this with an oscilloscope.

The tag is certainly not empty (checked with my smartphone).

    This topic has been closed for replies.
    Best answer by Peter Boringer

    Hello,

    I beleive you setup is correct

    The SPI interface is working properly the issue come from the command you send ( uint8_t invcommand[5] = {0x00, 0x02, 0x02, 0x01,0x21};) which is not a known command for the CR95HF

    Assuming you are in ISO 15693 you need first to initiate your protocol using the protocol select command I suggest to modify as follow : uint8_t invcommand[4] = { 0x02, 0x02, 0x01,0x21};

    according to the specification https://www.st.com/resource/en/datasheet/cr95hf.pdf see sheet 20/21

    The SPI answer 0x0E means that the busy flag is off only the bit 3 is significant.

    I can also suggest to check your SPI interface using the echo command described in the datasheet.

    This command will work after reset whatever is the protocol.

    Regards

    PB

    1 reply

    Visitor II
    August 22, 2018

    Hello,

    I beleive you setup is correct

    The SPI interface is working properly the issue come from the command you send ( uint8_t invcommand[5] = {0x00, 0x02, 0x02, 0x01,0x21};) which is not a known command for the CR95HF

    Assuming you are in ISO 15693 you need first to initiate your protocol using the protocol select command I suggest to modify as follow : uint8_t invcommand[4] = { 0x02, 0x02, 0x01,0x21};

    according to the specification https://www.st.com/resource/en/datasheet/cr95hf.pdf see sheet 20/21

    The SPI answer 0x0E means that the busy flag is off only the bit 3 is significant.

    I can also suggest to check your SPI interface using the echo command described in the datasheet.

    This command will work after reset whatever is the protocol.

    Regards

    PB