cancel
Showing results for 
Search instead for 
Did you mean: 

Communication with CR95HF does not work.

PToma.3
Associate

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

1 ACCEPTED SOLUTION

Accepted Solutions

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

View solution in original post

1 REPLY 1

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