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.

TRF7960 could not find picopass /iclass

Hello
I'm trying to modify the firmware trf7960evm to add iclass protocol.
Looking and reading the forum I found an answer I do Josh Wyatt where he directed another person by sending a PDF on "interoperability trf796x_v2."
In that file there was a presentation of how to approach the configuration of trf and command uses this protocol.
Try to follow this guide and I found several problems that surely you will be able to answer.

The file sets the ISO Control to "0x86" which is ISO15693 hight rate 1 out 4 FSK.
But according to the datasheet I could get from 2k PicoPass
the modulation amplitude does not the frequency, then no would have to select the 0x82?

Another rarely found in the file is that when a weapon PicoPass command such as ACTALL
the 4 bits are misconfigured more weight compared to the datasheet (more precisely the M1 and M0 bits are reversed)

The tests could take, even with these doubts gave me these results.
Sending a command ACTALL detect because the card seems to return something but in the registration of irq always detect collision and framing error.
I would like your opinion or if I'm wrong.

From already thank you very much to all for the help forum and also to Josh Wyatt for all the answers it gives.

  • Alejandro -

    in the picopass datasheet i have, it does indicate that ISO15693 single subcarrier option in the tag response is also supported.  This means that you should be able to set the ISO control register to 0x82 and then issue request flag byte which is matching the setting in the command string out to the card accordingly.  

    Regarding the M0 and M1 bits - i double checked this, and i did follow the format they are showing. where B7 = Parity, Bit 6 = M1, Bit 5 = M0, Bit 4 = K and Bits 3-0 = the instruction. Let me know if you have some different information as i did also go back to Inside and they confirmed that what i had documented was correct, too.  

     

  • Josh

    Thanks for the reply.
    The datasheet I'm using is 2lbs Date PicoPass ds 1.0.
    The bits M1 and M2 is as you put it, but written in the file for you for setting the command M1 = 0 and M0 = 1 and according to the data sheet this value does not correspond to ISO15693 but would have to be M1 = 1 and M0 = 0 or both 0.
    Could you solve me this doubt?
    and also consult you to confirm me if I'm facing either the routine acquisition of SN.
    ACTALL Command command, I hope 350us and for each time slot of 160us.
    And then would have to send the IDENTIFY command and wait for the sn but the CRC.
    The doubt arises because the ACTALL understood according to what the chip has to respond with SOF but that comes to the TRF and does not remove the OS?.

    Thank you again and I hope your answer.

  • Alejandro -

    i used the data sheet TPR0520A which is for their 32k(S) part. i observed that for the ACTALL command, M0=1 (setting for ISO15693-2 FSK support), thus ACTALL byte was 0xAA, because the command itself (lower nilbble of the byte is 1010(bin) = A(hex) and then

    K = 0 (must be set to 0 for all commands other than READCHECK),

    M0 = 1 (setting for ISO15693-2 FSK support)

    M1 = 0 (also the setting for ISO15693-2 FSK support)

    B7=1 (parity calculated over B0:B6)

    then the ACS (combo command) can be issued like this.

    ACTALL

    0xAA, response is SOF
    – TRF Command String: 0x8F, 0x90, 0x3D, 0x00, 0x10, 0xAA

    Identify

    0xAC, response is ASNB + CRC

    – TRF Command String: 0x8F, 0x90, 0x3D, 0x00, 0x10, 0xAC

    – ASNB = 0x58, 0xB7, 0x6B, 0xE0, 0x00, 0x40, 0x02, 0x1C

    – CRC = 0xAC, 0x98

    For this card

    Select

    0x21 + ASNB, response is SN + CRC

    – TRF Command String: 0x8F, 0x90, 0x3D, 0x00, 0x90, 0x21, ASNB (for this card used)

    – SN (Contents of Block 0, Chip UID) = E0120007035DBAC0

    – CRC = 0xE01B

  • Hi Josh,

    Do you have sample code or an algorithm to generate the CRC. I am struggling to get the same CRC values as you. If I read block 0 with your example in your power point presentation (0xAC 0x00 0x73 0x33) I manage to correctly receive data from the card. However if I calculate the CRC as described in the power point, only on 0x00, I get a CRC of 0x8C 0xCC. Any help would be appreciated!

    Regards,
    Gavin
  • Gavin - 

    You are using polynominal of 0x8408, with preset of 0xE012? 

  • Hi Josh,

    Yes I am, I'm obviously doing something wrong. I'll keep trying to try figure out why but any examples would be helpful.


    Regards,

    Gavin

  • please find two examples attached - one is for PicoPass, the other for ISO15693/14443B. 

    CRC_CALC_EXAMPLE_PICOPASS.zip

    CRC_CALC_EXAMPLE_ISO14443B_ISO15693.zip

  • also, i looked around more in the archive and found the ISO15693 code we used for the S6700 / RI-R6C-001A device, which did not have CRC generator or checker built in like the TRF79xxA family does.

    in the .h file you can see the start value defined, so you can change to correct one for PicoPass

    hope these examples help you out.

    iso15693_S6700.zip

  • Hi Josh, the PICOPASS Example is almost verbatim from the ISO15693 standard documentation. This is where I got my weird values for a readblock at block address 0. My sent data ends up being 0xAC 0x00 0x8C 0xCC instead of 0xAC 0X00 0x73 0x33 as in your "PicoPass Card Interoperability with the TFR796x/70A" I will try the rest of the examples you gave, but I'm very confused how I can't seem to get any further...
  • Your ISO14443B and ISO15693 example is also the same as the picopass crc example that is giving me issues, except with a different preset value as would be expected.. Little confused as to why this doesn't work...

    I have attached my version of the picopass CRC code with the changes I made to generate a CRC based on data with a value of 0. I compiled this in Bloodshed dev-C++ for testing.

    Kind regards,

    Gavin

    main.c
    #include <stdio.h>
    #define POLYNOMIAL 0x8408 // x^16 + x^12 + x^5 + 1
    #define PRESET_VALUE 0xE012
    #define CHECK_VALUE 0xF0B8
    #define NUMBER_OF_BYTES 1 // Example: 4 data bytes
    #define CALC_CRC 1
    #define CHECK_CRC 0
    int main(int argc, char *argv[])
    {
     unsigned int current_crc_value;
     unsigned char array_of_databytes[NUMBER_OF_BYTES + 2] = {0, 0x91, 0x39};
     int number_of_databytes = NUMBER_OF_BYTES;
     int calculate_or_check_crc;
     int i, j;
     calculate_or_check_crc = CALC_CRC;
    // calculate_or_check_crc = CHECK_CRC; // This could be an other example
       if (calculate_or_check_crc == CALC_CRC)
       {
       number_of_databytes = NUMBER_OF_BYTES;
       }
       else // check CRC
       {
       number_of_databytes = NUMBER_OF_BYTES + 2;
       }
       current_crc_value = PRESET_VALUE;
       for (i = 0; i < number_of_databytes; i++)
       {
       current_crc_value = current_crc_value ^ ((unsigned int)array_of_databytes[i]);
       for (j = 0; j < 8; j++)
       {
       if (current_crc_value & 0x0001)       
       {
       current_crc_value = (current_crc_value >> 1) ^ POLYNOMIAL;
       }
       else
       {
       current_crc_value = (current_crc_value >> 1);
       }
       }
       }
       if (calculate_or_check_crc == CALC_CRC)
       {
       current_crc_value = ~current_crc_value;
       printf ("CRC-ISO/IEC 13239 of { 1, 2, 3, 4 } is '3991'\n");
       printf ("Generated CRC is '%04X'\n", current_crc_value);
       printf ("The Least Significant Byte (transmitted first) is: '%02X'\n",
       current_crc_value & 0xFF);
       printf( "The Most Significant Byte (transmitted second) is: '%02X'\n",
       (current_crc_value >> 8) & 0xFF);
       printf( "Executing this program when CHECK_CRC generates: 'F0B8'\n");
       // current_crc_value is now ready to be appended to the data stream
       // (first LSByte, then MSByte)
       }
       else // check CRC
       {
       if (current_crc_value == CHECK_VALUE)
       {
       printf ("Checked CRC is ok (0x%04X)\n", current_crc_value);
       }
       else
       {
       printf ("Checked CRC is NOT ok (0x%04X)\n", current_crc_value);
       }
       }
       system("PAUSE");	
    return 0;
    }
    
    

  • well - try calculating just on the block #. 

    0x00 will give you 0x7333, 0x01 will give you 0xFA22

    in this case, the CRC is not calculated on the command byte, just the data being sent

  • Hi Josh,

    I found something interesting. My CRC code works perfectly fine when coded onto my Atmel atxmega16E5, but gave me odd results in dev-C++. Also, the CRC results I received in dev-C++ were correct if I subtracted my result from 0xFF for each byte....odd.

    Thanks for your help.

    One thing that might help others is I noticed I struggled getting a response from some iClass cards. It had to do with the flags located in the higher nibble. For example, using the ACTALL command 0xAA worked with half my RFID cards, while using the same command but with all upper nibbles set to 0 worked (be careful of the parity bit at the highest bit, this may still need to be sent). Due to this fact my "Select" Command is actually 0x81 not 0x21 as in your PicoPass presentation.

    Regards,
    Gavin
  • Gavin -
    0x81 is also legitimate - since the PicoPass data sheet shows that (this just means single subcarrier, manchester response is expected), i chose to show one of the other allowed ways to send out the command.

    according to the data sheet, M1 can also be set to 1, which is same thing as if M1 and M0 are both 0.
    so both 0x81, 0x21 and 0x41, would then just need to set the ISO control register up correctly to receive the response then.

    i would expect the cards to work all three ways - the reader will certainly handle them.