CR95HF error 0x71 - SPI interface

[gaby_bradu2]

I have a CR95HF transceiver connected over SPI interface running at 2MHz. When I send the protocol select command I get the error 0x71 (EinternalError) .

The IRQ_OUT goes after the 4-th byte low .

Clock, MISO, MOSI looks ok.

Send data 00 02 02 01 0d

Get data 0E 71 00

What means this error?

[Brian TIDAL]

Hi Gaby

In your first screen capture, the IRQ_OUT goes low before the end of the frame whereas it should goes low after the reception of the full frame. So it seems there is a transmission error on the first bytes and the CR95HF reacts immediately and send an error response.

Would you please make sure that your SPI clock frequency is not exceeding CR95HF max value (2.0 MHz).? On my side, I use a lower SPI clock frequency (~1.5 MHz) with an X-NUCLEO-NFC03A1 expansion board and I do not face communication issue. Would you please try a lower frequency than the 2.0MHz limit (e.g. 1.5 MHz) ?

Also, make sure

• to use either CPOL=0/CPHA=1 or CPOL=1/CPHA=1.
• to follow SPI characteristics from CR95HF Datasheet table 33 (in particular tSU(NSS))
• to wait for the completion of the startup sequence in particular to wait for t3 expiry before sending the first command

Here is an example of SPI initialisation code with STM32L476RG running at 48MHz for a SPI communication with CR95HF at 1.5 MHz :

 /* SPI1 parameter configuration*/
 hspi1.Instance = SPI1;
 hspi1.Init.Mode = SPI_MODE_MASTER;
 hspi1.Init.Direction = SPI_DIRECTION_2LINES;
 hspi1.Init.DataSize = SPI_DATASIZE_8BIT;
 hspi1.Init.CLKPolarity = SPI_POLARITY_LOW;
 hspi1.Init.CLKPhase = SPI_PHASE_1EDGE;
 hspi1.Init.NSS = SPI_NSS_SOFT;
 hspi1.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_32;
 hspi1.Init.FirstBit = SPI_FIRSTBIT_MSB;
 hspi1.Init.TIMode = SPI_TIMODE_DISABLE;
 hspi1.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
 hspi1.Init.CRCPolynomial = 7;
 hspi1.Init.CRCLength = SPI_CRC_LENGTH_DATASIZE;
 hspi1.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
 if (HAL_SPI_Init(&hspi1) != HAL_OK)
 {
 _Error_Handler(__FILE__, __LINE__);
 }

Once the SPI is initialized and the startup sequence is completed, the echo command (0x55) can be used to check the communication interface.

Here is an example of SPI comminication:

>>> (0x00) 0x0202010D (Protocol Select)

<<< (0x0E) 0x0000 (Result Code reply)

Zoom on CR95HF response (0x0E) 0x0000

Feel free to share more details regarding your implementation of the CR95HF such as:

• board being used (e.g. X-NUCLEO-NFC03A1)
• MCU being used (e.g. STM32 on nucleo board)
• Software being used (e.g. ST driver)

Rgds

BT

[gaby_bradu2]

Hi Brian,

thanks for the answer.

   MCU - STM8AF52

   board - own design, (serial interface - MCU - SPI /CR95HF)

   no standard ST driver used

The hardware is ok, it works since about 2 years. The only function from MCU was just after restart to manage the /IRQ-IN singnal after this just get serial data & send over SPI. The PC was responsible for CR95HF configuration & data transfer (protocol select, WR registers, rd/wr data, etc...)

Now it's intend to do the initialization directly by MCU, this means:

   low impulse on /IRQ_IN

   send protocol select cmd.

   send write registers cmd.

Back to the problem:

   MCU manages /IRQ_IN - PC does the initialization & data transfer : everything ok

   MCU manages /IRQ_IN & initialization (protocol select, wr register) : bad answer from CR95HF

Startup sequence:

t0 : 4ms

t1 : >50us

t3: 12ms (tested up to 2s - no change)

SPI setting CPHA=0, CPOL=0 (CPHA=1, CPOL=1 tis also ok)

fSCK - 2MHz (tested with 1MHz - the same)

The timing regarding Table 33 is checked - looks ok. tSU(NSS) ~7us (set/reset from the main loop)

I suppose it is something critical with the timing on start-up or between the bytes, commands...

I get very often as an answer for the first telegram after /IRQ_IN pulse an IDN response.

With the oscilloscope I can see nothing :(

I changed the start sequence:

   /IRQ_IN pulse

   delay

   echo command

   get echo answer

   select protocol command

   get answer

   write registers command

   get answer

In this way it works.

Attached some fotos, maybe it will be help somebody else :)

Thanks,

Regards,

GB

[Brian TIDAL]

​Hi Gaby,

here is an example of startup sequence (delay unit is ms):

Init:
 retry = 5
 Send_nIRQ_IN_Pulse
 Send_Reset
 while (Send_Echo == Error) && (retry --!= 0)
 Send_Reset
 if retry ==0
 abort
End_init
 
 
Send_nIRQ_IN_Pulse
 Set_N_IRQ_IN
 Delay(1) /* t0 */
 Clear_N_IRQ_IN
 Delay(1) /* t1 */
 Set_N_IRQ_IN
 Delay(11) /* t3 */
End_Send_nIRQ_IN_Pulse:
 
 
Send_Reset
 SPIDeselect;
 Delay(1)
 SPISelect()
 SPISendReceiveByte(CONTROL_RESET) /* Send Reset Control byte over SPI */
 Delay(1)
 SPIDeselect()
 Delay(3)
 Send_nIRQ_IN_Pulse
End_Send_Reset

Before issuing the first command, a reset control (0x01) is sent after the t3 expiry. This is used in case the MCU has restarted  (e.g watchdog or sw reset) to avoid to have the CR95HF in an unknown state.

Then an echo command is sent. In case of error, the CR95HF is reset and a new echo attempt is done. Once an echo reply is properly received, the first command can be issued.

Rgds

BT

[gaby_bradu2]

Hello Brian,

it has to be a reason for such a complex initialization.

Intresting is also that a reset is possible only over SPI :)

I implemented it like in your example & it is ok.

Thanks,

regards,

GB