• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 16 subscribers
  • Views 683 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.

TRF7970A: Problem reading NDEF file in Type4 state machine

Robert Abad
Intellectual 470 points
Part Number: TRF7970A

Hi All,

I'm seeing some weird behavior in the Type4 state machine.

When an NDEF file is received, it gets placed into g_pui8T4TBuffer.  It generally looks something like this:

In this example, g_pui8T4TBuffer is at memory address 0x20002414.  It starts with 0xD1010354 which is the start of an NDEF header (0xD101).

If I keep the tag in the field long enough, the Type4 state machine fills the buffer differently:

At the same address, the first two bytes in the address are the NDEF length then followed by the NDEF header.  It's not clear to me why this happens.  The only way I can get out of this state is to remove the tag from the RF field and place it back in to reset the T4 state machine.

Any thoughts?

Regards,
Robert

  • 0
    TI__Guru*** 128125 points
    Hello Robert,

    Looking at the State Machine, the only way I could see it happening is if in the T4T_READ_NDEF state, the ISO_7816_4_sendReadFile API is called without the offset for the NLEN of the message included. It should look something like ISO_7816_4_sendReadFile(g_ui16T4TNdefIndex+2,g_ui8NdefMaxReadBytes), but if the +2 isn't present then it would cause the NLEN to be read out of the tag a second time.
  • 0 in reply to Ralph Jacobi
    Intellectual 470 points
    Hi Ralph,

    I think the problem is in one of my state machines that interacts with the Type4 state machine. I believe what I originally posted is now a non-issue.

    Regards,
    Robert