cr95hf won't pole after idel command

[MUnge]

Hi i am using an cr95hf. After using an idel command and waking up afterwards any command I send after the idle wont work. I don't even get a polling response. Unfortunately I can't find anything in the cr95hf datasheet telling me if i need to reset or anything similar after exiting the idle mode. Also I am using the cr95hf as the plug and it is connected to an atmega 128 and I am communicating via SPI.

[Brian TIDAL]

​Hi

here is a log file with timestamp showing the idle command being used, a tag being detected and the various polling activities being resumed.

On my side I use the following Idle command:

070E0A21003801180024606070803F00

Can you send me the command you are using on your side and a log of the data being sent/received over the SPI?

I suggest you send a echo command to check whether the CR95HF is back in active mode after the response of the Idle command.

Also feel free to have a look to x-cube-nfc3 firmware package (version 2.0.0, make sure to refresh your brower to get the latest release). The idle command over SPI is implemented as part the firmware (st25r95SPIIdle).

AN3433 calibrationalso gives some important information. In particular, before using Idle a has to be performed. This is implemented in the x-cube-nfc3 firmware package.

Thanks

Rgds

BT

[MUnge]

hi,

I send the idle command {07,0E}

with the following parameters:

{0x02,0x21,0x00,0x79,0x01,0x18,0x00,0x01,0x60,0x60,0x94,0xFD,0x3F,0x01};

after the idle i get a 000102 so it is detecting a tag.

But then sending an echo or anything else wont work.

Sending an echo and polling it just wont give me the 8 telling me that polling is done.

If I send numerous comands it will at some point start returning 01020000 over and over again.

best regards Michael

[MUnge]

I attached the log if you want me to format it differently let me know.

This time the echo command right after idle actually worked but the command after that already gets a unexpected(not possible) response.

The commands after the echo are from the cr95hf datasheet for nfc forum tag type2 for 14443-A. If I use these commands without the idel before hand i get a correct UID.

[Brian TIDAL]

​Hi Michael,

See my comment below:

• 07h Idle Command Code
• 0Eh Len
• 02h Wake-up flag: only bit Tag detector is set. I would recommand to set as well Wake up in low IRQ_IN level ==> 0Ah instead of 02h
• 2100h Enter Control: Tag Detection ==> OK
• 7901h WakeUp Control: the updated version of the ST25R95 / CR95HF DataSheet recommands to use value 3801h
• 1800h: Leave Control: tag detection ==> OK
• 01h: WU period: on my side I've used 24h.
• 60h Osc start default value: ok
• 60h: dac start default value: ok
• 94h DacL See below
• FDh DacH. The maximum value of the DAC is FCh (6 bits DAC, value coded on b7-b2, b1-b0 are rfu). I believe DacL/DacH are erroneous. The recommended guard band is 2 dac steps (08h) and the DacL/DacH values should be (DacRef - guard, DacRef + guard). DacRef is computed during calibration procedure. The x-cube-nfc3 firmware package 2.0.0 implements the calibration procedure. For my X-NUCLEO-NFC03, DacRef is 78h and DacL=70h, DacH=80h. Feel free to reuse the calibration procedure from x-cube-nfc3 firmware package. Make sure to have no tag in the operating volume when performing the calibration.
• 3Fh swing count default value ok
• 01h max sleep

Can you give more details about your setup:

• which board do you use:
  • X-NUCLEO-NFC03A connected to an MCU board
  • custom board. If custom board, make sure that the OscStart parameter (HFO stabilization delay) is aligned with the characteristic of your oscillator
• do you use  ST driver library (x-cube-nfc3) or your own driver? if using x-cube-nfc3, which version?
• when entering low power mode on ST25R95 / CR95HF, is the MCU also entering low power mode?
• can you send me the result of the IDN command (0x01) so that I have the HW revision number of the device
• how do you poll the ST25R95/CR95HF for the answer of a command? In your traces I see strange values in POLLING <REC> lines
• what is your SPI configuration (speed, CPOL/CPHA)

I will have a deeper look to your traces.

Rgds

BT

[MUnge]

I am using a custom board. The Plug is directly connected to the atmega128. I use my own driver. The MUC doesnt enter low power mode. The IDN command returns:

I poll by sending the byte 0x03 untill i get a 00001xxx where i dont care what *** is.

I did a similar thing to the calibratio but iterating over all possible values for dacref and got 94 as the first result rendering 102 instead of 101.

For the Wakeup controll the value i am using is the one stated for wkae up by tag detection.

I changed the dacLow and High to 88 and 98 and got a wake up by tag detection eventhough there is no tag even remotely close to the antenna.

[MUnge]

Hi Brian,

I am currently discussing with my boss that it is possible that we are reading the bits shifted and thats why we are getting 06 instead of 08 when polling. So don't bother trying to figure out what the traces mean it is possible that our SPI reading configuration is wrong which would result in utter **** in the traces. We will inverstigate this tomorrow. I ll get back to you with the results.

Best regards Michael

[Brian TIDAL]

​Hi Michael,

I recommend to use <WU Source> = 0Ah in order to always be able to control the device from the MCU i.e. to be able to exit the device from wake up mode if the MCU needs to communicate with the reader.

For the calibration, feel free to reuse the st25r95CalibrateTagDetector() API from the x-cube-nfc3 firmware package provided by ST (fast 8 steps dichotomy procedure). If your DacRef is 94h, then DacL is 8Ch and DacH is 9Ch (if 94h is the value where the answer is timeout instead of tag detected, this is this the DacRef value).

For the WUCtrl parameter, the CR95HF is now named ST25R95 and the ST25R95 datasheet gives the appropriate value in table 26:

These two bytes (WuCtrlL and WuCtrlH) define the wake-up resources

• 0x0400: Hibernate
• 0x3800: Sleep/Field detector
• 0xB801: Tag detector calibration
• 0x3801: Tag detection 

This is the value used in ST x-nucleo-nfc3 firmware.

Can you resend the return value of the IDN command (it was empty in your answer).

Regarding the polling mechanism, an easy way is to simply read the GPIO status of the MCU PIN connected to the ST25R95 IRQ_OUT. See st25r95SPIPollRead() API. This signal can also trig an interrupt. Can you give more details on your polling mechanism implementation (e.g. is there a timeout implemented and how is handled the timeout)?

Can you send a polling just after the wake up reply and before sending any data  and then check that the ST25R95/CR95HF reply has bit 2=1 (Data can be sent)

Rgds

BT

[MUnge]

Hi thanks for your answer. I ll adjust the dacL and dach and try again. Also the idn returned :

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

And right now we dont have the irq_out connected to the MUC since we thought that we dont need it when using SPI.

If I am interpreting you right you are asking if we have a timeout after polling where the chip does sth else?

We just poll right after sending the command. By sending 0x03 and reading what the chip returns in a loop until we get the bit 3= 1.

I will try polling right after we read the wake up source and see what we ll get there.

Best regards

Michael

Edit: So I polled right after reading the wakeup source and got 0x06 which means that the bit 2 is one if i am correct.

[Brian TIDAL]

​Hi Michael,

the IRQ_OUT is just an option (it might be an interesting option if you plan to enter the MCU in low power sleep mode and exit from this mode when there is a reply from the CR95HF)

My question regarding the polling was the following:

• do you poll for ever (i.e. if the CR95HF does not reply, the MCU is stuck)
• or do you poll until a timeout and then try to recover if there is no reply

Other question regarding the polling:

• do you poll like a machine gun until bit3=1, i.e.
  • SpiSelect
  • send 03h
  • loop send 03h and read response until bit3=1
  • SpiDeselect
• or do you poll on request i.e
  • SpiSelect
  • send 03h
  • send 03h and read response
  • SpiDeselect
  • return bit3 value
  • do other stuff and re-poll

Do you have the possibility to plug a logic analyzer on the SPI (MOSI/MISO/CLK/SS) + IRQ_IN + IRQ_OUT and provide the trace so that I can better help on investigation?

Thanks

Rgds

BT