• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 16 subscribers
  • Views 507 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: SDM with Mifare

TRF7970A: SDM with Mifare stops after 2 clocks on SDM Bit clock

Jorick Astrego
Intellectual 760 points
Part Number: TRF7970A
Other Parts Discussed in Thread: MSP430FR5962

Hi,

We currently have the same issue as the referenced post. But we unlike the original poster, we don't have a module that works

>What is the issue faced with OK Module?
=> OK module is no problem, we get the output.
   The problem is why NG module does not continue (just 2 clocks) with the same modules, but not the same individual.
   Currently we have 5 % failure ratio, not continuing the output.

I understand that the post got pulled offline due to NDA issues, but we can discuss things in private as we have a current NDA with TI and access to the Mifare code in our Secure access.

Also we understand Mifare is not recommended for current designs but we have to support it while the client is rolling it's updated card infrastructure.

  • 0
    TI__Guru*** 128195 points
    Hello Jorick,

    What MCU are you using? Is it an MSP430, or another MCU?

    MIFARE Classic with the TRF7970A is very timing dependent, and if the timing is off between transitions of steps documented in the app note, it may not work: http://www.ti.com/lit/sloa214

    If there is a non-TI MCU being used, we aren't in position to help though if needed I can supply a logic capture which has all the timings for you to cross check.
  • 0 in reply to Ralph Jacobi
    Intellectual 760 points

    Hi Ralph,

    We are using a MSP430FR5962 for this. I will take another look at the timing, thanks!

  • 0 in reply to Jorick Astrego
    TI__Guru*** 128195 points
    Hello Jorick,

    If it's an MSP430 MCU then I would recommend initially trying to port the code as closely as possible to it. Use the same clock frequency and everything, even if that's not the final clock frequency you need to use. You should be able to get it working that way.

    Then if you need the change the clock frequency, you will need to adjust some of the delays in the Mifare functions to account for the changes.
  • 0 in reply to Ralph Jacobi
    Intellectual 760 points

    Hi Ralph,

    We checked the timing and are running on 8Mhz just like the example.

    But why would it be dependent on the MCU timing as it is the SDM Bit Clk (I/O 5) that comes from the TRF7970A that stops? The SS pin stays low

    What we see on the scope looks nearly exact like the NG logic output of the referenced post (http://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/667/Compare.xlsx)

    The code is a port of sloa214 with the static mifare lib recompiled from (TRF7970A_Parallel_SPI_Firmware_MIFARE_OK). We can't use this firmware as our uart has been routed to another MCU

  • 0 in reply to Jorick Astrego
    TI__Guru*** 128195 points
    Hello Jorick,

    It's not just the bit clock but the sampling of the signals based on the bit clock as well as the timing between certain setup portions.

    I was going to ask about the porting of the MIFARE lib, so thank you for clarifying that point.

    Now that I am back in the office, I checked through my emails to find the discussion that was pulled offline. It looks like the solution had been caused by them not always resetting the FIFO data after a FIFO read, can you check if such behavior may be in your setup as well? I don't have high hopes this is the root cause and solution as it was a very unusual solution to us, and the behavior was only showing on a small subset of chips and they had well over 90% working. Plus the solution was not something we were ever able to explain, but I figure it's worth bringing up...

    Lastly, what hardware are you using? Is it a custom board?
  • 0 in reply to Ralph Jacobi
    Intellectual 760 points

    Hi, thanks for your quick reply. Yes it is a custom board. I'm now thinking, we replaced the crystal in the reference design (Crystek

    017486 Rev A) with something smaller (ABM7-13.560MHZ-D2Y-T) due to space constraints.

    I tried to match the specs as far as I could compare the datasheets and it was listed somewhere with the TRF7970A, but maybe it doesn't work that well for Mifare?

  • 0 in reply to Ralph Jacobi
    Intellectual 760 points
    Hmm, my co-worker implemented a FIFO reset and we get pulses now. Thanks!
  • 0 in reply to Jorick Astrego
    TI__Guru*** 128195 points

    Hello Jorick,

    Wow that's great to hear. Very odd quirk that the FIFO reset solves the issue... but it's worked 2 out of 2 times now.

    I'll have to look into adding that into the software example we have on the web...