• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 16 subscribers
  • Views 407 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.

Original question:

TRF7970A: DESFire EV1 AES encryption on the MSP432P401R

TRF7970A: AES_Encryption.lib

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

I've been working on the MIFARE DESFire EV1 AES Authentication With TRF7970A Application Report using an MSP-EXP430F5529LP. I've managed to port the firmware properly; but the compilation process is failing because the AES_Encryption.lib needs to be re-built to run on the board I'm using. I understand that the source code is not publicly available; is there anything else I can do to get this to work?

Thank you

  • 0
    TI__Guru*** 131810 points

    Hello Wilmer,

    I can help with this when I am back in the office on Monday as I was out all day today. I'll need to recompile the library.

    You may want to search E2E if anyone has asked the same and received a new library file. You could just use that instead of waiting on me.

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    Wow, that's great. 

    Thank you so much

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

    Hello Wilmer,

    Find the AES Encryption library for the MSP430F5529 attached: AES_Encryption.lib

  • 0 in reply to Ralph Jacobi
    Intellectual 371 points

    Hi, 

    Everything seems to work perfectly. The detection, anti-collision, and the selection process all complete. But, communicating with a MIFAIRE DESFire tag doesn't seem to be working (and I need this to work to configure the tag for AES). Some commands do not give a response. 

    For example, the Iso14443aDFEV1GetAppId() function causes a communication error to occur (the error is that the card didn't respond). But, other functions like the SelectApplication() does work, providing a valid response from the tag when selecting a valid and invalid tag ID.

    I've been stuck on this for a couple of days and I'm unsure where to go from here (should I post this issue as a new question?). I believe the issue lies with the how the communication between the TRF and the tag is implemented; but I'm unsure what it is.

    Any help would be greatly appreciated.

    Thank you 

  • 0 in reply to Wilmer Suarez
    Intellectual 371 points

    So, I've concluded that every second command I send fails. I tried sending the same command (a command that I know works) twice, and the second transmission always fails. What could be the issue...?

  • 0 in reply to Wilmer Suarez
    Intellectual 371 points

    So, I've found the issue I was having. In the demo commands, the IpduBlockNumber argument passed to the MIFAIRE DESFire commands alternates between 0 & 1 allowing the command responses to be received. Is there a resource I can be directed to where I can learn more about what this argument means/does?

    Thank you, and sorry for the trouble

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

    Hello Wilmer,

    That is probably due to not having the right bit set in the I-block command. The lowest bit of the first byte alternates between 0 and 1 to indicate the block number of the command. This is hardcoded in the TI example, but should be flexible for yours. If every second command fails, that's probably what is going on. You may want to read up on the ISO14443-4 spec to understand it better.

    Rule A. The PCD block number shall be initialized to 0 for each activated PICC.
    Rule B. When an I-block or an R(ACK) block with a block number equal to the current block number is received, the PCD shall toggle the current block number for that PICC before optionally sending a block.

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

    Hello Wilmer,

    To clarify I checked and the ui8IpduBlockNumber is only hardcoded in the Aes_authenticate API.