TRF7960EM direct ISO14443A commands

It would be uselful for me too!

I'm actually trying to set up the TRF7960 to work in direct mode and I'm looking for some hints too!

How long is the bit period for the ISO14443A protocol?

thanks!

byee

I've just successfully sent a WUPA command using direct mode zero :)

In the MISO pin I've got the raw data: 1 00100000 00000000 01

the first bit is the StartOfCommunication, after that there are 2bytes LSB (0x04 and 0x00) and then 2more bit 0 and 1.

The answer 0x04 0x00 is the correct ATQA respons of the Tag after the WUPA 0x52 command for the Mifare tag. 

The other 2bit may be the parity bit of each one of the previous bytes? I didn't found any spec. in the ISO about it.

Im looking for some explaination! thanks

EDIT: or maybe the parity bit follow every byte like that: 1 00100000 0 00000000 1

that sounds more correct ;D

while playing with direct Mode I had a little issue:

after powerOn and after entering the directMode i couldnt modulate anything if the CLK pin was high. Initally I've tried by touching the PCB with my finger, then I've found which pin made this issue, and then i fixed it in my own code.

So after setting up the TRF7960 registers for entering the direct mode zero I just put the Clock pin low, and  now everything is ok.

I dont know why it happens

Hi, im here again, 
i'm trying to use the directMode 0 to communicate with a Mifare card, im sending the commands encoded with the Modified Miller encoding and now Im trying to decode the Modified Manchester raw stream.

Manually decoding works perfectly, i know how Modified Manchester encoding works and I'm trying to use a Microchip PIC18 to decode that signal.

Anyone could give me some hints about how to decode that signal?  

with some tags the raw stream starts low, with others it starts high like in the nextt picture Shouldnt it start always low?

the pic is showing the first bits of the answer to the WUPA 0x52 command :   0x04 0x00

any suggestion?

The TRF7960 does require the use of Direct Mode 0 for the authentication of Mifare cards. Mifare is not fully compliant to ISO14443A (this is well known) but it does use the ISO14443A air interface in the beginning, so you don't need to go into Direct Mode 0 quite yet as you can use the part in Direct Mode 2 (default) for this part of the sequence.

But if you really want to do it this way, then get a copy of ISO14443-2 and -3 standard.

-2 will explain to you how to decode this and -3 is for the commands.

 BR-

Josh

Thanks for the answer.

I've already done the first sequence (anticollision and set tag active) using direct mode 2. Now I was trying to use directMode 0. After sending the commands with a Modified Miller encoded signal, i get the reply but i'm having some problems with the synchronization of the subcarrier.

May I use the directMode 1 for reading a Mifare tag? It would help me decoding the manchester subcarrier signal.

Im going step by step, im not yet into the crypto stuff, so I still dont have everything clearly in my mind :)

You could/should use Mode 2 through the bit-frame anticollision sequece and up to the select acknowlege (SAK) - this is the point at which the Mifare card is no longer compliant to the standard and you will have to use Direct Mode 0 with the TRF7960 as a result. You cannot use Direct Mode 1 here because of this, it is just a mismatch.

By the way - it may help you to check out this page here: http://www.cs.virginia.edu/~kn5f/ and scroll down a bit to a section called TI EVM firmware for some helpful downloads, etc.

BR-

Josh

I've already found that link, It will help me a lot when i will need some hints for the crypto procedure and so on.

coming back to the direct modes, there are 3 possibility

-standard direct mode 2

-direct mode 1 - direct modulation and bit stream output

-direct mode 0 - direct modulation and subcarrier output

so with direct mode 1 I should get the bit  stream output  that its still UNframed, so with Mifare cards i will be able to send commands with encrypted parity bits and get the answer from the data bit stream unframed no? or im wrong? :)

thanks and sorry for all these questions :)

Ciao! 

no the parity bit will be incorrect/opposite of what it should be in Direct Mode 1 with the TRF7960 and the Mifare cards - exactly the point i was attempting to get across.  

no worries on the questions - this is exactly what the forum is for I think.

Keep'em coming if you have issues.

BR-

Josh

I have experimented with this a bit, some time ago, and couldn't ever quite figure this out either. 

So, in normal mode, when you read a mifare card, you can read 8/9ths of the data, and will get a parity error (most likely), with no way to know which bytes had correct (or incorrect) parity. If you knew that much information, you would be able to piece the information back together. 

So it does seem that Direct Mode 1 should work, but i actually haven't been able to see what a direct mode 1 bitstream looks like. I have DM0 working seems that it should just be a matter of setting the dir_mode bit in the ISO Control Register, but alas, when i try that, nothing comes back on IO_5/IO_6 after i output.

Ti's eval code uses Direct Mode 0, and it is working fine for me, processing the subcarrier is not as difficult as you may think. TI's method samples IO_6 into a word and uses a window to filter that into a signal, i think, my processor is quite a bit faster and i have the luxury of attaching IO_6 to a counter input, i have an interrupt that checks this counter every half bit time, 4 counts means the signal was modulating, 0 means no modulation, and i continue until i get a full bit of no modulation, make sense? 

My processor's clock is derived from the TRF's clock, so i don't have to worry about resyncing during those long block transfers, but i came up with a method before this processor that worked out well enough, i sampled for just less than half a bit time, and would resync on either two modulation or two no-modulation periods, as long as you keep within an 1/8th of bit within where you expect to be, it's possible.

good luck, let me know if you get anywhere with DM1 

You will not be successful using DM1 with the TRF7960 and these cards. Don't waste any time on it - you must use DM0 for these devices.

BR-

JDW

Robby Morrill said:

 So, in normal mode, when you read a mifare card, you can read 8/9ths of the data, and will get a parity error (most likely), with no way to know which bytes had correct (or incorrect) parity. If you knew that much information, you would be able to piece the information back together. 

Yes, because in directMode 2 (normal mode) SOF, OEF, parity bits and CRC bytes are checked and removed so direct mode 2 cant work with mifare cards. its well know.

Robby Morrill said:

So it does seem that Direct Mode 1 should work

I was thinking the same after reading the datasheet: The transmit side is identical; the user has direct control over the RF modulation through the MOD input. This mode is provided so that the user can implement a protocol that has the same bit coding as one of the protocols implemented in the reader, but needs a different framing format.

So my question is: whats the differences between DM0 and DM1? In what case would be useful to use DM1?

Robby Morrill said:

...but i actually haven't been able to see what a direct mode 1 bitstream looks like. 

Here i have 2 logs of the command WUPA 0x52 made with my logic analyzer.

The first is DirectMode 0:

The second is the DirectMode 1, after the WUPA command i get 9 clock pulse (pin 22) 8bit data LSBFirst (0x04) and the parity bit (0)

Robby Morrill said:

 my processor is quite a bit faster and i have the luxury of attaching IO_6 to a counter input, i have an interrupt that checks this counter every half bit time, 4 counts means the signal was modulating, 0 means no modulation, and i continue until i get a full bit of no modulation, make sense? 

My processor's clock is derived from the TRF's clock, so i don't have to worry about resyncing during those long block transfers, but i came up with a method before this processor that worked out well enough, i sampled for just less than half a bit time, and would resync on either two modulation or two no-modulation periods, as long as you keep within an 1/8th of bit within where you expect to be, it's possible.

Good to know! i never tought about using a counter pin, I will try this solution as soon as possible. Im using my own custom board so I easily may change the connections.

Im still confused about why DM1 wouldnt suit with Mifare cards, because I can get every 8bit of data and also the single parity bit. Or maybe there is still something that i dont know well about the Mifare protocol.

If it's so, i will focus more with the DirectMode 0 .

@ Axxe (i think)

You can use Direct Mode 1 (or 0 or 2) for what you are showing here with ReqA/WupA, the Anticollision loop (all the way to getting the SAK) - the problem is when you go to authenticate the device...this is when you must drop into DM0. The why is a parity bit that can't be handled any other way than directly in this case with the TRF7960.

I am working on the comms section of the latest rev of the DS...i am putting in section (with LSA plots) to help explain this better - so look for that soon or just keep posting. i do have screen shots and some other docs i made on this topic as well.

JDW 

Any plans on the next rev of the part to have a way to disable this ... apparently mandatory parity check when in ISO 14443A mode? So is that what is really happening? As the part decodes the input, it does a check of the parity bit, and only if the bit is correct it will generate the DM1 signal? 

Seems like i am still doing something wrong, however, remember, during the first phase of Authentication, the reader (me), sends out a request to authenticate, a total of 4 bytes: 0x160 0x100 0x1F5 0x17b (with parity) and that is transmitted unencrypted, so the TRF in normal mode shouldn't complain yet. The response from the card will be a pseudo random number, and that too will be unencrypted, sent with valid parity bits. 

I'm not seeing that random response when i do nothing extra but set the dir_mode bit in my "DirectModeStart()" routine. Oh, and don't get me wrong, i have no plan to get DM1 working, my system works great with DM0, and the most processor intensive part now seems to be the output anyway, so DM1 doesn't buy me much. Just seems like that, at least, should work. 

Thanks for your help Josh, i really appreciate it! 

yes - we do have some improvements coming in the next revision IC (TRF7960A) to improve ISO14443TypeA operations. As you may know, Type A is an inferior approach as compared to the way ISO14443B works, but it (Type A) is very popular/widely used worldwide, so in the meantime - please see our sort of recent doc here ==> http://www.ti.com/litv/pdf/sloa153 these are some firmware design hints and known issues with workarounds on existing IC as it is with the Type A cards and SPI operations, too.

BR-

Josh

yes - we do have some major improvements coming in the next revision IC (TRF7960A) to improve ISO14443TypeA operations to ease the firmware burden a bit. As you may know, Type A is an inferior approach as compared to the way ISO14443B works, but it (Type A) is very popular/widely used worldwide, so in the meantime - please see our sort of recent doc here ==> http://www.ti.com/litv/pdf/sloa153 these are some firmware design hints and known issues with workarounds on existing IC as it is with the Type A cards and SPI operations, too.

BR-

Josh

This is a fantastic document, thanks!

Are there any more tips that i may be missing (broad question, i know), but we are releasing a layout for fab in the coming days, and doing a final review today, so, you know of any updated schematics for the EVM? We have room to add more things like that buffer resistor on IO_6, but you know if that (or similar) is documented anywhere?

Robby -

i have released the TRF7960TB board and the design files for it here: http://www.ti.com/litv/zip/sloc221

to me this is perhaps a cleaner schematic and layout than what we have with the current TRF7960EVM, since that board supports SPI and Parallel modes, whereas this one is set up for SPI only. Have a look and i would appreciate any feedback you or anyone else has on this.

Also, user manual is here: http://www.ti.com/litv/pdf/slou297

and product page is here: http://focus.ti.com/docs/toolsw/folders/print/trf7960tb.html

We also have ISO14443A+ RFID demo kit available with Stellaris LM3S9B96 eval board here: http://focus.ti.com/docs/toolsw/folders/print/dk-em2-7960r.html

with the request for FW project on that one here: http://focus.ti.com/docs/toolsw/folders/print/sw-dk-lm3s9b96-em2-trf7960-14443a.html

the FW request link isn't working for me, I'm logged in, it takes me to that Sorry! cannot find link page, anyway to verify it's there from your side?

*nvm, worked fine outside of chrome... 

Josh Wyatt said:

I am working on the comms section of the latest rev of the DS...i am putting in section (with LSA plots) to help explain this better - so look for that soon or just keep posting. i do have screen shots and some other docs i made on this topic as well.

Oh, thanks for the explanation! 

So by my side I will focus on direct Mode 0 and I will check time to time if you will release some good docs!

Thanks again!

Robby -

i just went in and was able to get to the page where you fill out the fields to request it.

Maybe the webpage had some issues at that moment  - maybe try going in from the product page again in a bit.

So - go here ==> http://focus.ti.com/docs/toolsw/folders/print/dk-em2-7960r.html 

then scroll down to :

Related Products

Robby -

you should have just gotten your activation ID for the Stellaris FW.

Hi Josh Waytt,

Can you send me the link for downloading DK-EM2-7960R Firmware Development Package as I am not able to get the download link for the same.

Regards

Mohit - 

i have asked Stellaris team to fix the dead link - thanks for bringing that to our attention.

Hi josh,

Thanks for your reply. So do I need to click the same link which you have provided in this mail chain?

Can you tell me how much time would this take?

Many Regards.

working on it - the page is actually owned by another group at TI who NRND'ed their MCU  - so bear with me.

Hi Josh,

Can you now please provide me with a stable link for DK-EM2-7960R Firmware Development Package

Regards

Mohit - 

sorry for the delay - the IT folks are still working on it...apparently they took down a lot more than just the link itself. 

Mohit - the Stellaris Mifare SW link is now back operational! 

see REQUEST button on this page ==> http://www.ti.com/tool/dk-em2-7960r 

Hi Josh,

I thank you for your committed response during need.

Many Regards.

Besides, I also want to know from where I can download stellarisware which will support all versions of LM3S9B96. What I mean is that I have DK-LM3S9B96 which have RevB1 uC but I have later versions of chip which may not be supported by the s/w that came along with the kit. The most latest version i have heard is only having LM3S9D96.

Mohit,

Try this: http://www.ti.com/lsds/ti/microcontroller/tiva_arm_cortex/c_series/tm4c_arm_cortex-m4/tools_software.page?DCMP=Stellaris&HQS=Other+OT+stellarisware.  Stellaris is now the first part in our TIVA line, I believe what you are looking for the latest TIVAware. 

You can probably find out more on the Stellaris Forum.

Thanks,

JD