Need sample code for TRF7970A to authenticate, read/write Mifare classic tags

here is the FW image to load into TRF7970AEVM and then GUI to run with it. 

8407.TRF7970A_MIFARE.7z

5621.TI-GUI-Mifare.zip

Hi Josh,

Thank you very much for the FW image and the GUI (both dated Feb 24 2009).

I would appreciate if you can send me the code for the firmware.

I was able to download the image onto TRF7970AEVM.  The module detects mifare class tags.   However, when I run the GUI, I get "invalid Entry" error before the GUI window opens.  Then I see " Failed to open port COM1" error all the time.     My computer is Windows XP.

Is this the latest GUI with a mifare tab?

 I have another non-mifare GUI (dated Jan 24 2011) and the firmware source code (July 25 2011) for TRF7970A, but this does not authenticate, read/write mifare tags.  And this is much more stable.      I have been using this GUI to experiment with the source code. 

Thanks,

Harry

Here's an update.

I manually selected a com port for the GUI to get around the error " Failed to open port COM1".

And I was able to read from all of the blocks in a sector!

I still want the source code of the firmware image.

Thanks,

Harry

HarryKim1 - 

i just sent it to you, its also subject to same clickwrap agreement you agreed to when you downloaded the other code. 

thanks! 

Hi Josh,

I was able to read/write Mifare classic tags with 4 byte UIDs with the image and the GUI, but can't read 7 byte UID tags.   I thought it was supposed to read 7 and 10 byte UID tags also.

Am I misunderstaning something?

Hi Josh,

Here's an update.

With the following stuffs that you sent me for me, I was able to create a program to read/write 4 byte UID tags without using GUI.   

8407.TRF7970A_MIFARE.7z

TRF7970A_Parallel_SPI_Firmware_MIFARE-OK.zip (source code for TRF7970A_MIFARE)

5621.TI-GUI-Mifare.zip

However, with the original firmware that comes with the TRF7970A, 7 byte Mifare classic UID tags were recognized if you use the 14443a tab.   But with the Mifare tab, 7 byte UID tags are not recognized most of the time.

Here's what I get when it works.

Register write request.
010C00030410002101080000
Register write request.

12:35:47.991 --> 0109000304F0000000
12:35:48.100 <-- 0109000304F0000000

12:35:48.100 --> 0109000304F1FF0000
12:35:48.209 <-- 0109000304F1FF0000

12:35:48.209 --> 0109000304A0010000
12:35:48.334 <-- 0109000304A0010000
14443A REQA.ý(4400)(88041BB720)(04)(5A5D2B80AC)[041BB7205A5D2B80AC]

where 041BB7205A5D2B80AC is the UID.

If you have the source code of the firmware that recognizes, reads/writes 7 byte UID tags, can you please send it me ?

Thanks,

Harry

Harry - 

you have a double size UID (seven bytes) here of: 041BB75A5D2B80

in the first pass, the 88 indicates at least double size UID is present, the 0x20 is the BCC (XOR of the four preceding bytes)  then the second pass yields the rest of the UID 5A5D2B plus its BCC of those four preceding bytes, which is 0x80. 

what is the SAK response of this tag you are using?

8371.TypeA_UID_retrieval.pdf

Hi Josh,

Thanks for the pdf file.

The SAK response should be 0x08 according to the Mifare classic tags I am using.

And I see the SAK response to Select command to be 0x08 when I use 4 byte UID tags.

If I use the TRF7970A EVM module with the firmware that is already loaded, I see that 7 byte UID tags are recognized without failure.    

Note that I am using the GUI made for Mifare to read/write.  It has "Mifare" tab.    On the 14443a tab,  I see the following result when I click "set protocal" and "execute".

Register write request.
14:50:17.038 --> 0109000304F0000000
14:50:17.147 <-- AGC Toggle

14:50:17.147 --> 0109000304F1FF0000
14:50:17.256 <-- AM PM Toggle

14:50:17.256 --> 0109000304A0010000
14:50:17.413 <-- 14443A REQA.
[041BB7205A5D2B80AC,7F]

14443A REQA.
(04)[041BB7205A5D2B80AC]
15:31:20.928 --> 0111000304A2041BB7205A5D2B80AC0000
15:31:21.053 <-- 0111000304A2041BB7205A5D2B80AC0000
14443A Select.
(4400)(04)[00]

This means that the SAK response is 0x04 for 7 byte UID tags that I use, right?

 On Mifare tab tab, I see the same result when I click "Scan for card".   However, it doesn't advance to authenticate.

I guess the GUI for Mifare is not compatible with the firmware on the module.

Can you send me the source code for the firmware that is loaded on the module?   (LOT 041020133 and its id is 3389185PD1) and at least this module recognizes 7 byte UID tags although I can't read/write.

Also if you have the firmware that can read/write 7 byte tags, please send it to me.

Thanks,

Harry

Hey Harry,

See if the attached IAR Project is useful.  I haven't tried this code out to see if it's exactly what you were wanting, but looking at the code it does seem close.   

14443.c has the Anti-collision and Select functions.  The Select function does recognize that the UID is not complete. 

if((buf[1] & BIT2) == BIT2)
	{				/* UID not complete */
		kputchar('(');
		for(j = 1; j < RXTXstate; j++)
		{
			Put_byte(buf[j]);
		}			/* for */

		kputchar(')');
		ret = 1;
		goto FINISH;
	}

I don't see the code currently acting on this (but I could be wrong).  If this happens, then the loop just needs to executed another time.

Thanks,

JD

Attached is an updated 14443a.c file, that will be in the updated EVM Firmware.  The project as a whole doesn't have Mifare support, but this anti-collision process is the same for A and Mifare.  

You will see that the Iso14443aLoop function is called recursively until the entire UID has been received and that tag has been selected.  

line 246:

		    		if (Iso14443aSelectCommand(select, nvb, &complete_uid[uid_pos]))		// uid not complete
		    		{
		    			cascade_level++;
		    			uid_pos += 5;
		    			nvb = NVB_INIT;
		    			Iso14443aLoop(cascade_level, nvb, uid);
		    		}

Hi Josh,

Thanks for the code you have posted.

Since I don't have any working GUI to read/write 7 byte UID tags, I am using the GUI independent program I wrote to read/write 4 byte UID tags successfully.

With the program, I was able to get the 7 byte UID from SelectCommand function, but the authentication process does not work after that.  is there any difference in authenticating 4 byte UID tags and 7 byte UID tags?  That is, MifareAuth1 and MifareAuth2 are not supposed to work with 7 byte UID tags?

I wonder if you can you read/write any 7 byte UID Mifare tags with any GUI/firmware on TRF7970AEVM? 

If that doesn't exist, do you have any plan to release such firmware/GUI  in the near future?

Thanks,

Harry

Josh,

4 byte UID tags is ok with MifareAuth1, but 7 byte UID tags fail. 

void MifareAuth1(unsigned char key_select, unsigned char block, unsigned char *_uid, unsigned char length)
{
   
.................

  DirectModeTransceive( DIRECT_MODE_SEND_PARITY | DIRECT_MODE_RECV_PARITY,
                       auth1_command, 4, 0,
                       auth1_response, &recv_bytes, &recv_bits);
 
  if(recv_bytes != 4 || recv_bits != 0) {
  }

With 7 byte UID tags, this function fails because  recv_bytes is 0 and recv_bits is 4. 

I used the same key_select (key A with FFFFFFFFFF set at  the chip delivery) , the same block number for 4 and 7 byte UID tags.

Can you help me with this problem?  Any suggestion?

Harry

Hi J.D.

Sorry for not recognizing that you responded to my question earlier.  I just assumed that it was Josh.

I already have the same zip file you have posted.  And I am aware of those code that you have mentioned.

I suspect that the reason for authentication failure is with SAK return for 7 byte UID tags when executing  selectCommand.

For 4 or 7 byte UID tags, SAK is supposed to be 08.   However, only with 7 byte UID tags, SAK becomes 00.

select command is executed with 0x93 (CL1), and then with 0x95 (CL2).  the UID (first 5 bytes of the UID for the first select command and then the second 5 bytes of the UID because there are extra 3 bytes, first byte for the double size UID and 2 BCC bytes).  

With the first select command, SAK is 04 and with the second select command, SAK is 00.

Is SAK supposed to be 08 when executing the second select command with 0x95?

I just wish I had working GUI/firmware that can read 7 byte UID tags.  So far, none of them worked.

Were you able to read any Mifare 7 byte UID tags?

Harry

Hey Harry,

 The SAK shouldn't be the problem.  Both 0x00 and 0x80 are acceptable responses and will depend on the tag used.  Below is the SAK bit coding from the ISO14443 Spec.  

I currently only have 4 byte UID mifare tags.  They mifare tab works for these if I do "Scan for Card" then "Authenticate B".  It only seems to get through authentication about 50% of the time, but once I get a successful authentication it works fine.  This is using the firmware and GUI attached above.

Here is the relevant log file:

16:23:33.362 --> 0109000304A0010000
16:23:33.488 <-- 0109000304A0010000
14443A REQA.ý(0400)(7DE27DC624)[7DE27DC624]
16:23:33.505 --> 010A0003041850000000
16:23:33.628 <-- 010A0003041850000000
Request mode.
[]
16:23:33.645 --> 010D000304A27DE27DC6240000
16:23:33.771 <-- 010D000304A27DE27DC6240000
14443A Select.
(0400)[08]

16:23:35.365 --> 010E000304C0FFFFFFFFFFFF0000
16:23:35.490 <-- 010E000304C0FFFFFFFFFFFF0000
Crypto1 set key.
Initialization ok

16:23:35.511 --> 010F000304C161007DE27DC6240000
16:23:35.658 <-- 010F000304C161007DE27DC6240000
Crypto1 authentication step 1.
Card nonce: 2BB56D03. Success

16:23:35.676 --> 010C000304C2112233440000
16:23:35.837 <-- 010C000304C2112233440000
Crypto1 authentication step 2.
Authentication ok. Success

Once you get past the "14443A Select.  (0400)[08]" step, the Tag has been selected and the UID shouldn't matter. The UID isn't used anywhere in Mifare Authentication, only the Key and a Random number.

If you look at authentication step 1 command "010F000304C161007DE27DC6240000" you will notice the UID being sent back in.  It seems to just be stored in a struct and never actually used, but I'll check this further.   

I don't believe your problem is related to the difference in the size of the UID's of your different tags, but possible due to the difference in their antenna's and/or internal hardware.  Try putting some space between the tag and the EVM's antenna and see if that makes any difference.  

Thanks,

JD

Hey Harry,

Actually it does seem that the firmware/authentication is somehow dependent on the UID.  I'll continue to dig into why this is.  Once I understand this I'll probably understand why 7 byte UID's are having trouble.   

Thanks,

JD

Hi JD,

Yes, if you don't have the correct UID, MifareAuth2 fails.  I wrote a program to read 4 byte Mifare Classic UID tags, but when I mess up UID intentionally, authentication fails. 

I am supposed to receive 7 byte UID Mifare Classic tags from NXP either today or tomorrow.  I will let you know the test result.

Hopefully it will work fine since the firmware I received from TI is supposed to deal with 4, 7, and 10 byte UID tags.  And so far it was successful with 4 byte UID tags.

Thanks,

Harry

Hey Harry,

Were you able to test with the 7 byte UID MIFare tags?  How did that go?  

I confirmed that the UID is actually used in the MIFare authentication process.  This means we can't put in the wrong UID.

In Level 2 Authentication, 4 bytes of the UID are being used.  This is straight forward when using 4 byte UIDs, since the entire UID is being used.  With 7 byte UID's, I believe only the 4 MSBytes are used.  

I'm trying to confirm this currently, although I don't have any 7 byte UID MIFare tags to test with.  The way the code is written,  it appears to be using the 4 MSBytes of the UID regardless of size.  This means it should work with the 7 byte UID's, assuming using the 4 MSBytes is the correct process.  

Thanks,

JD

Hey Harry,

I was able to *simulate* a 7 byte UID using a 4 byte UID MIFare tag.  What I did was manually send the host commands to walk through the MIFare Authentication steps, but I sent in a 7 byte UID (with the first 4 bytes being the actual UID for the tag).  The Firmware used the 4 MSBytes and authenticated the tag.  

I'm still haven't confirmed that the 4 MSBytes are the correct bytes to use, but the firmware does handle the 7 byte UID.  

Log Using 7 Byte UID sent in:

16:06:07.431 --> 010A0003041000010000
16:06:07.463 --> 010C00030410002101080000
16:06:07.585 <-- 010A0003041000010000
Register write request.
010C00030410002101080000
Register write request.

16:06:07.607 --> 0109000304F0000000
16:06:07.730 <-- 0109000304F0000000

16:06:07.750 --> 0109000304F1FF0000
16:06:07.874 <-- 0109000304F1FF0000

16:06:07.896 --> 0109000304A0010000
16:06:08.031 <-- 0109000304A0010000
14443A REQA.ý(0400)(5EE69AA684)[5EE69AA684]         // 4 byte UID from Tag
16:06:08.052 --> 010A0003041850000000
16:06:08.178 <-- 010A0003041850000000
Request mode.
[]
16:06:08.202 --> 010D000304A25EE69AA6840000
16:06:08.332 <-- 010D000304A25EE69AA6840000
14443A Select.
(0400)[08]
16:06:14.186 --> 010E000304C0FFFFFFFFFFFF0000
16:06:14.319 <-- 010E000304C0FFFFFFFFFFFF0000
Crypto1 set key.
Initialization ok

16:06:19.545 --> 0112000304C161005EE69AA684AAAAAA0000         // 4 byte UID + 3 extra bytes to simulate 7 byte UID
16:06:19.693 <-- 0112000304C161005EE69AA684AAAAAA0000
Crypto1 authentication step 1.
Card nonce: ADF93E6F. Success

16:06:27.169 --> 010C000304C2112233440000
16:06:27.335 <-- 010C000304C2112233440000
Crypto1 authentication step 2.
Authentication ok. Success

Thanks,

JD

Hi JD,

Unfortunately, I couldn't obtain 7 byte UID tags yet.   But I will definately have samples (Mifare Classic) next Monday.   So I will let you know the result next Monday(Sept 23rd) afternoon.

I tried Mifare Ultralight 7 byte UID tags, but it failed with MifareAuth2().

I wonder if the current firmware I have from TI is only for Mifare Classic tags or is supposed to work with all Mifare variants.

Best Regards,

Harry

Hey Harry,

The MIFARE section of this code is made to interface only with MIFARE Classic.  MIFARE Classic uses a proprietary protocol, and according to this wiki page, the Ultralight doesn't have any of the security of Classic.  Most of the other MIFARE tags use difference encryption methods as well.

Hope this helps,

JD 

Hey Harry,

So I found out this code isn't going to work in it's current state with 7 Byte UID's.  Page 11 of this document explains the steps needed to be followed in order to have full functionality with the 7 Byte UID.  Below is a the figure explaining the steps.  

Basically, with the 4 Byte UID, we can just feed the 32 bits into the Authentication.  Now, we need to create the 32 bit NID by using a CRC functionality of the 7 Byte UID (with 1 buffer byte), then feed in this NID.  

There are already some CRC functions in directmode.c that could possibly be used as are or slightly modified in some way to generate this NID.  You will need some 7 Byte UID MIFARE tags to test with though to tell if it's working correct though.

BR,

JD 

HI JD,

Finally I got hold of Mifare Classic 7 byte UID tags to test.

The following simplified version of my standalone program works fine with 4 byte UID tags through all iterations, but with 7 byte UID tags, it works only for the first iteration.  At the first iteration, everything went well and read/write into sector0, but at the second iteration,  AntiCollisionSequenceA() does not call AnticollisionLoopA() even if it is called multiple times because the value of  i_reg does not become 0xFF.

====================================================================

sector=0

While(sector < 16) {

   success=0;

    while(success==0) {

         AntiCollisionSequenceA(0x01); //  this function is called twice to pass for 4 byte UID tags

          // I modified AntiCollisionSequence to return a success flag, either 0 or 1

     }

   SelectCommand() // called with the correct UD for single or double size UID tags

  MifareSetKeyCommand();

  MifareAuth1()  // called  with a correct 4 byte  UID for  single or double size UID tags

  MifareAuth2()

  MifareTransceive(); // read or write blocks from the current sector

  sector++;

}

==============================================================

If you comment out code after AntiCollisionSequenceA() in the main while loop, 7 byte UID tags still fail at the 2nd iteration with AntiCollsionSequenceA() while 4 byte UID tags have no problem.    Do have any idea what might be the cause of the failure at AntiCollsionSequenceA() at the second iteration with 7 byte UID tags?

Thanks,

Harry

Hey Harry, 

So did you already implement the CRC and such that I presented above, to be able to read Sector 0?

I'm not sure I quite understand what you are seeing.  You are saying that you are not getting into AnticollisionLoopA? 

	if(i_reg == 0xff || i_reg == 0x02) 
	{
		for(i = 40; i < 45; i++) buf[i] = 0x00;  // No UID Currently
		AnticollisionLoopA(select, NVB, &buf[40]);
		if(POLLING) LEDtypeAON;
	}
	else
	{
		LEDtypeAOFF;
	}

So you are not getting back into this a second time because i_reg already equals 0xff?  Can you tell me what I_reg does equal in this case?  

I don't think you have to start all the way back at the beginning to read the next sector.  I believe you should be able to go straight to authenticating the next sector.

BR,

JD

Hi JD,

At the second iteration with 7 byte UID tags, i_reg equals to 0x00 when I call AnticollisionSequenceA() repeatedly.  So AntiCollisionLoopA is never called.

But with 4 byte UID tags, i_reg equals to 0xFF for every iteration.

It would have been very nice if I didn't have to go from sector to sector without going through AntiCollision and select, etc, but I tried your suggestion a few weeks ago hoping that it would work, but it didn't work.  That is why I iterate all of the steps for each sector.  

If you try the latest firmware and Mifare tab on the GUI with 4 byte UID tags, you have to start from the beginning everytime you change from one sector to another.  That is, you have to click "Scan for card", then "Authenticate" for every sector.

Thanks,

Harry

PS  I didn't implement CRC you have suggested.  Instead I used CL2 bytes UID3,UID4,UID5, UID6 as specified on Page 13 in the same document you have indicated.  That worked for authentication!

Hey Harry,

We're having some trouble locating 7 byte UID MIFARE tags.  Do you mind pointing us to the vendor you received them from?

Thanks,

JD

Hi JD,

We purchased a few tags from the following vendor just to testing.  It costs $3 per tag.  It took almost 10 days for delivery.  But we are not using these for our products

http://www.smartcardfocus.us/shop/ilp/id~655/Mifare_1K_Card_7_byte_UID/p/index.shtml

I have actual tags we are thinking to use in our product.   They are 25mm diameter tags that has 21 mm aluminum antennae.

If you let me know your address, I am willing to send you a few because I want you guys to help me resolve the issues I am having.

I am still having AntiCollsionSequenceA at the second iteration just with Mifare classic 7 byte UID tags (both tags from smartcardfocus and the 25 mm diameter tags I mentioned.)   It almost acts like that data transfer freezes after the entire sequence to access to a sector is processed without any problem for the first iteration.

 With 4 byte UID tags, depending where I place the tags (usually under the reader), I see exactly the same problem.    Maybe code adjustment inside AntiCollsionSequenceA is needed?

Harry

Hey Harry,

We ordered some of those tags but if you really don't mind sending me a few it would speed things up.  

Address:

J.D. Crutchfield

13532 N, Central Expressway

MS 3824

Dallas, TX 75243 

You can send me either a few of the tags you ordered or the ones you think you may use for your product.  

Thanks,

JD

Hi JD,

I am going to send you both type of tags Monday because I am not at my office today.

My group has to make a decision which RFID reader we are going to use for our upcoming product.

Hardware guys prefer TRF7970A, but software guys prefer another reader from other vendors because its software is easier to handle than the source code from TI.    If I can make 7 byte UID tags to work with TRF7970A, it will be a lot easier to convince everybody to go with TRF7970A.    Unfortunately we have to make a decision within a month one way or another because of our project schedule.

If you don't mind, please let me know your e-mail address.

Thanks,

Harry

Hi JD,

I mailed both sample tags to you by Fedex.  You should receive them by tomorrow afternoon.

I downloaded a bunch of android apps to my Samsung Galaxy S4 and tested a bunch of RFID tags I have.

Although some of apps are advertized to read Mifare Classic tags, none of them couldn't detect Mifare Classic tags (tags from smartcardfocus.com and our company sample tags with 4 byte or 7 byte UID tags)

However, all of the apps are able to detect Mifare Ultralight tags(ISO14443 type A) I have and ISO 15693 type tags.

Have you tried any android NFC reader apps to read 4 byte UID Mifare Classic tags?

"NFC Android tag free" app is supposed to detect Mifare Classic tags, but it didn't work.

Harry

Harry - 

as Mifare Classic tags are not actually NFC Type 2 tags, all Android handsets not having NXP PN544 (or a derivative) will not recognize them as they are free from the proprietary chokehold placed on them by the NXP NFC stack running in those devices.  

Basically, this means any Google phone, starting with the Nexus 4 and Nexus 10 (the S4 is one of these later released and now correct devices) will treat the Mifare Classic tags for what they are.  

Hi Josh,

Thanks for your explanation on why my S4 couldn't read Miface Classic tags.   I found out that S4 has a NFC chip from Broadcom in it instead of a NFC chip from NXP.  S3 has a NFC chip form NXP.

Anyhow did you guys receive and test the 7 byte UID Mifare Classic tags I have sent?

Harry

Hi JD,

Did you receive the Mifare Classic tags with 7 byte UID that I sent?   It was supposed to be delivered to you a week ago.

Thanks,

Harry

Hey Harry,

I received the tags mid-late last week.  They probably were hung up in our internal mail system.  

Anyway, I'm going to start working on getting these running now.  Is it still hanging for you when you're looping?

Thanks,

JD 

Hi JD,

OK.  I am looking forward to hearing the test result from you.

It is still hanging during anti-collision routine after accessing the first sector, no matter what sector the first sector may be.  As I told you earlier, 4 byte UID tags had no such issue.

Harry

Harry Kim1 said:

At the second iteration with 7 byte UID tags, i_reg equals to 0x00 when I call AnticollisionSequenceA() repeatedly.  So AntiCollisionLoopA is never called.

But with 4 byte UID tags, i_reg equals to 0xFF for every iteration.

Hey Harry,

I'm currently working to make the code handle 7 byte UID MIFARE Classic cards, which I'm making progress on, but in the mean time I'll try and take a look at this issue.   

	if(REQA) buf[5] = 0x26; /* send REQA command */
	else
		buf[5] = 0x52;		/* send WUPA command */
	RequestCommand(&buf[0], 0x00, 0x0f, 1);  // Send REQA and Get ATQA Response            
	irqCLR;					/* PORT2 interrupt flag clear */
	irqON;

	if(i_reg == 0xff || i_reg == 0x02) 
	{
		for(i = 40; i < 45; i++) buf[i] = 0x00;  // No UID Currently
		AnticollisionLoopA(select, NVB, &buf[40]);
		if(POLLING) LEDtypeAON;
	}
	else
	{
		LEDtypeAOFF;
	}

For i_reg to = 0 at this point, and not go into AnticollisionLoopA, there had to be an RX timeout in the RequestCommand function.  Basically, the Tag didn't respond to the REQA or didn't respond fast enough (within ~20 ms).  

I would guess that this has more to do with the Tag's internal state machine than the 7 byte UID.  The tag may need an RF field toggle to reset the state machine back to the beginning.  

How are you running these iterations?  Are you using a script that is just using the Host Commands over UART, or did you do this running loop in the MSP430's firmware?

Thanks,

JD

Hi JD,

I am running a loop in the MSP430's firmware.

Basically, it is like this.

int sector=0;

 While(sector < 16){ 

     int success=0;

     while( success==0){

          AntiCollisionSequenceA();   // This hangs at the second iteration (when sector=1) with 7 byte UID tags

          if (success) break;

      }

      // rest of the command functions to select, authenticate and access to current sector

     ++sector;

}

Thanks,

Harry

Alright Harry,

Try toggling the RF field during this Loop.  You can see a similar behavior in the Find Tags Function in automatic.c.

Basically, add this:

        // Turn RF On.  I'm sure you are already doing this somewhere.  
        command[0] = ChipStateControl;
	command[1] = 0x21;
	WriteSingle(command, 2);

        //Turn RF off. 
	command[0] = ChipStateControl;	///* turn off RF driver
	command[1] = 0x01;
	WriteSingle(command, 2); 

        // Then Add a small Delay
        delay_ms(1);

Add these here:

Harry Kim1 said:

int sector=0;

 While(sector < 16){ 

     int success=0;

 // TURN RF ON

     while( success==0){

          AntiCollisionSequenceA();   // This hangs at the second iteration (when sector=1) with 7 byte UID tags

          if (success) break;

      }

      // rest of the command functions to select, authenticate and access to current sector

 / / TURN RF ON

     ++sector;

 // SHORT DELAY

}

 This should fully restart the tag's state machine, so if you get through once, you should get through all the times.  Also, I feel like we shouldn't have to start all the way at the beginning, so once I get this code up and running with a Docklight script I'll see if I can figure out the proper flow.  

Thanks,

JD

Hi JD,

I have already coded your suggestion when I wrote my stand-alone program a month ago by emulating the code in FindTags().

That is why I was puzzled.  It works fine with 4 byte UID tags, but not with 7 byte UID tags.

Thanks,

Harry

HI JD,

I have noticed there is a common problem in timer interrupt.

Inside RequestCommand(called by AnticollsionSequenceA), i_reg doesn't become 0xFF because  timer interrupt occurs 20ms failing to receive a response from a 7 byte UID tag.

With some of 4 or 7 byteUID tags, I noticed the similar problem inside SelectCommand.  i_reg doesn't become 0xFF because timer interrupt occurs in 10 ms failing to receive a response from a tag.

The result is consistent with each tag.  Some of them don't have the problem and some always have the problem.    Some of tags I have sent you could have the same problem.

However, all these tags can be read/written using RFID apps on a smartphone( For example, Samsung galaxy S3)

Any suggestion?

Thanks,

Harry

Hey Harry,

This interrupt shouldn't really be the problem because the tags should respond faster than 20 ms.  This timeout interrupt is to keep us from waiting forever if the tag does not respond.  

All tags will fail at some stage a small percentage of the time due to noise, range, etc. but will make it through on the next polling cycle.     

You can increase these delays to 50 or 60 ms to give the tag more time to respond.  The tags response to REQA/WUPA should be fairly short.  

Harry Kim1 said:

Some of them don't have the problem and some always have the problem.    Some of tags I have sent you could have the same problem.

Do you mean that 1 type of tag always fails while the other doesn't or do you mean that inside 1 type of tag, a few always fail and a few don't?

Thanks,

JD

Hi JD,

A certain tag (either 4 or 7 byte UID tag) always fails the same way.      For example, sending select command sequence is done in about 1 ms, but receiving the response sequence from the tag takes more than 20 ms for some tags consistently.  That is why timer interrupt occurs and i_reg does not become 0xFF.

Harry

Hi JD and Josh,

Josh sent me the following  several weeks ago.

8407.TRF7970A_MIFARE.7z -- This is the firmware image (dated Dec 10 2012)

TRF7970A_Parallel_SPI_Firmware_MIFARE-OK.zip -  source code for the firmware (dated Feb 15 2012)

The problem I have been having with some of the 4 byte UID tags occurs only with the version that I built with the source code from Feb 15, 2012.   I didn't change any code and simply rebuilt them to create a firmware image to download.

 And I used this source code to write my stand-alone program and I see the same problem, that is, the reader fails to receive response from the tag in 10 ms after the Select command is sent to the tag.

 If I download  the firmware image (dated Dec 10, 2012), I don't see the problem.

As you can see, the difference between the firmware image and the source code is10 months apart.     I wonder if the firmware image was built from the source code Josh sent.    If not, can you send me the source that was used to build the firmware image?

Thanks,

Harry

Hi JD,

I found out the reason why some of 4 byte UID tags didn't work with selection command.

BCC (this is the 5th byte right after 4 byte UID) you get from AnticollisionLoopA is incorrect for some tags consistently.

For example,  BCC for a 4byte UID (E6 4F 8C 34) should be 11 in hex, but I get 10. It seems that it is usually off by 1.   ( I have only two tags that have this problem.)

If I correct the BCC to the right value, it works fine.

However, with the firmware image (dated Dec 12, 2012) didn't have this problem.   Unfortunately I don't think I have the source code for it as I mentioned in my previous reply.

Thanks,

Harry

Hi JD,

All of the tags(either 4 or 7 byte UID) fail to get the correct BCC when the BCC (5th UID byte) is odd number in hex.

The firmware I have built using the source code I received (dated Feb 15 2012) receives only even BCC number correctly.   Basically, all BCCs turn into even if they are odd numbers when the UID is received from the tag when a pre-select command sequence is transmitted to the tag like I explained in my previous reply.

I have more than 10 tags with odd BCC, all of them have the same problem, but not tags with even BCC.

Once again, with the firmware image (dated Dec 12, 2012) I don't have this problem.

How are things going with the time-out interrupt problem with 7 byte UID tags?

Thanks,

Harry

Hey Harry,

I've had some real high priority issues drop on me in the last couple weeks so I apologize for the delay.  I'm still working to get the Mifare code updated and see what you are seeing.  

As for the difference in firmware, I haven't been able to locate the source for the earlier image yet.  Honestly, there wasn't much version control on these examples until I joined the team earlier this year.  I'll have Josh still look for this.  

Having issues with only odd BCC's seems like a rather strange issue.  I can't think of anything currently that should cause this issue, but I'll probably end up running into it as well...  

I talked with Eddie and  I believe he said he supported a call with you last week?  He mentioned that 15693 tags might be a possible solution for you guys?  If so, 15693 is much simpler and we could get you up in running much faster.  

Thanks,

JD 

Hi JD,

Thank you for updating the status.   I was wondering for a while.  Mifare Classic is still on the table, so I like to find out whether TI's sample code can support 7 byte UID tags.

Yes, we are also looking into 15693 tags seriously because of tag cost and simplicity,etc.   Our application does not need much security.  A tag is supposed to store a bunch of information like a library card.

Have you dealt with RFID tags from Infineon?  Jason Kriek at TI suggested this option.   The product is my-d™ vicinity plain SRF 55V10P.    They are compliant to ISO 15693/18000-3.     I don't have any sample tags yet, but does this mean that we could use the same source code that supports any tags compliant to ISO15693 like Tag-it HF-I Plus?

Thanks,

Harry

Hey Harry,

If you aren't worried about security, I wouldn't go through the trouble of using Mifare classic.    

Those my-d tags look pretty good and should work great.  

The same source code should be able to work will all the 15693/ISO18000-3 commands.  If you can read and write to our Tag-it tags, then you should be able to read/write those tags as well.

Thanks,

JD 

I am working on TRF7963A to access MIFARE classic cards. With the sample code from TI, it only able to do anticollision and select the card.  But it doesn't have the code for the authentication and tag memory access.

Can anyone share the code to authenticate and read/write MIFARE classic cards to me?

Thank you very much.

Alan.

Alan - 

do you need for 16 bit MCU (i.e. MSP430) or 32-bit (i.e. Cortex M) and if either which one? If something different, then please let us know that detail, too. 

Also, what does your schematic look like? Reason i ask is because you do need to put the TRF7963 into Direct Mode 0 to handle the non-standard method used by the MFC cards after activation and selection. This means you will need to use the MOD pin during auth and read/write operations. See attached - and let us know which MCU, then we can assist you in getting this code. Its not out on the web directly because its subject to export control - so this is why we need to go through a short process, based on your MCU type. 

3513.Mifare Classic Deep Dive Training.pdf

Hi Josh,

Thank you for your reply.

Currently I am working on the TRF7970A EVB which replaced the chip with TRF7963A. On the board it has a MSP430F2370 MCU. On the EVB, it has the MOD pin connected to MCU.

Alan.