• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 16 subscribers
  • Views 492 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TRF7970A: Porting TRF7970A demo code to an STM32F207

Wilmer Suarez
Intellectual 371 points
Part Number: TRF7970A
Other Parts Discussed in Thread: MSP-EXP430F5529LP,

Hello,

I have been working on a MSP-EXP430F5529LP, attempting to run the MIFARE DESFire EV1 AES Authentication Application Report. I have successfully been able to read/write/configure DESFire EV1 & EV2 cards. I am now attempting to port the working firmware to an STM32F207; but I'm having some issues detecting the cards. 

I am configuring the TRF7970A with the following:

Commands:

  1. Soft Initialization command
  2. Idle command
  3. Reset FIFO command

Register Configuration:

  1. ISO control register: 0x88
  2. ISO 14443 TX options register: 0x01
  3. RX wait time register: 0x07
  4. Modulator control register: 0x01
  5. RX special settings register: 0x30
  6. Regulator Control: 0x01
  7. NFC target level register: 0x00

The rest of the registers are left in their default state. This configuration works perfectly on the MSP dev board. This configuration doesn't seem to work properly when the firmware is ported to a stmf207 (ARM cortex m3 processor).

MIFARE Classic cards are detected without issue. EV2 cards are sometimes detected, and EV1 cards aren't detected at all. I cannot seem to pinpoint the issue.

 

  • 0
    TI__Guru*** 132565 points

    Hello Wilmer,

    The AES Library may need to be recompiled for ARM M3 unless you already got a new library.

    Beyond that, NFC is very timing based so given the processor speed you may need to adjust the delays.

    Also what is the SPI speed?

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    I'm ignoring the authentication for now.

    The SYSTEM clock on the STM32 is 25 MHz and I'm dividing it by 16 for the SPI_CLK. So, 1.5625 MHz. Is this too slow? In the MSP dev board, the SPI_CLK is configured as 2 MHz.

  • 0 in reply to Wilmer Suarez
    TI__Guru*** 132565 points

    Hello Wilmer,

    The minimum SPI clock is 2 MHz, spec'd on Page 11 Section 5.4.

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    Thank you for your help! Can't believe I missed that. That definitely made things a lot better. The DESFire EV2 and Classic cards are being detected now; but not the EV1 cards.

  • 0 in reply to Wilmer Suarez
    TI__Guru*** 132565 points

    Hello Wilmer,

    From a technology standpoint there is no difference for detection for EV1 and EV2. I know EV1 tags are well known for having been off-tuned from 13.56MHz to help with security by reducing the read range. Maybe the issue with those EV1 cards are that your reader antenna isn't tuned well and therefore isn't picking them up (if so, most would be likely due to narrow bandwidth). You can see details about proper antenna tuning here: http://www.ti.com/lit/pdf/sloa241 - in your case you'd want a Q of around 7.

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    Hello,

    Turns out that the issue is the antenna. I will just continue to use the EV2 cards for this project since they seem to work seamlessly. 

    I have one last issue, I've successfully been able to get through both cascade levels for the anticollision process and am able to receive the UUID of the cards. The issue now is that I am getting no response when transmitting the RATS command. I've made sure to send the proper parameters (128-byte maximum framing 0x70) with the CRC enabled; but the ATS response isn't being received. I can privately share the code I've written for the layer 4 process if needed.

    I thank you for all the help you've given me so far

  • 0 in reply to Wilmer Suarez
    TI__Guru*** 132565 points

    Hello Wilmer,

    Make sure you are sending with CRC. It should look like this:

    	g_pui8TrfBuffer[ui8Offset++] = 0x8F;		// Reset FIFO
	g_pui8TrfBuffer[ui8Offset++] = 0x91;		// Send with CRC
	g_pui8TrfBuffer[ui8Offset++] = 0x3D;		// Write Continuous
	g_pui8TrfBuffer[ui8Offset++] = 0x00;		// Length of packet in bytes - upper and middle nibbles of transmit byte length
	g_pui8TrfBuffer[ui8Offset++] = 0x20;		// Length of packet in bytes - lower and broken nibbles of transmit byte length
	g_pui8TrfBuffer[ui8Offset++] = 0xE0;		//RATS Command
	g_pui8TrfBuffer[ui8Offset++] = 0x70;	        //RATS Parameters: 128 byte max receive and CID = 0

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    Hello again Ralph,

    I've have gotten my reader to successfully write/read/configure MIFARE DESFire EV2 cards thanks you your help; but I am noticing a large drop in the acquisition range of the reader during the ISO14443 Layer 4 process (and subsequently the data exchange and authentication) as apposed to the anti-collision process.

    This was not apparent when testing on the MSP430 dev board. The read range there was great during all processes. The TRF7970A  is supplied with 3.3V by the MSP430 board. The STM32 (and the TRF) I'm porting to, however, is only being supplied with 2.8V.

    I'm just wondering if this difference in supply voltage is what is affecting the read range, and if there's anything that can be changed in the firmware (register configuration of the TRF) that can help with this issue? I am unable to change the input voltage of the system.

    I have tried changing the Regulator and I/O Control Register (0x0B) to manually configure the regulators to their maximum settings; but that does not seem to help. 

    Thank you

  • 0 in reply to Wilmer Suarez
    TI__Guru*** 132565 points

    Hello Wilmer,

    Make sure Regulator Control is set to 0x00 if you are at 2.8V. If you try and set it higher, it can have a negative performance impact as the device tries to drive elements at voltages that supply cannot meet.

    Beyond that, you will get lower read range at lower voltages. Plus the read range will have more challenge with longer packets. The reason is the RFID Reader is providing the RF field the tag is energizing with but for long replies, more energy is used on the tag side so that can reduce read range for reading data vs just identification.

    Ultimately, 2.8V is unfortunately very low for a system using EV2 cards.

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    So, I've added a small delay (1 ms) after every Trf797xRawWrite(). This caused the detection to work a lot better, increasing the range as well, the EV2 cards are being read about 1cm above the antenna. Why is this the case?

  • 0 in reply to Wilmer Suarez
    TI__Guru*** 132565 points

    Hello Wilmer,

    Given the duration, I'm guessing that it is because it allowed the tag to harvest more power between commands. That's usually why short delays improve performance although usually only see that on dynamic tags. EV2 might just be more power hungry. You still may need to review the antenna tuning to ensure the bandwidth is good. Proper tuning would help with this too. 1cm is very short even for EV1/EV2.