• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 2 answers
  • Subscribers 16 subscribers
  • Views 1365 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.

RF430FRL152HEVM: using as a low-level 15693 transponder

Oleg Tcaregorodtcev
Intellectual 525 points
Part Number: RF430FRL152HEVM
Other Parts Discussed in Thread: MSP-FET

Hello,

I'm investigating the possibilities to circumvent the so called "RF Stack" in RF430's ROM code and instead write my own 15693 card simulation (so that all the Inventory, Read Block, etc are custom implemented). Is it enough to use "NFC Only Example Project" and override interrupt handlers for RF13M (instead of overriding ROM callbacks) and implement all the functionality there using RF13M* registers?

Thanks,

Oleg

  • 0
    TI__Guru*** 128255 points
    Hello Oleg,

    It may be possible but the part was not designed for such an implementation.

    You can reference this post (and a second one linked by Alex in that post) to read about custom commands, but note that replacing more than 2-3 commands with custom commands will slow down RF responses and may result in violations of ISO15693 standards for response times: e2e.ti.com/.../1580243

    The default project from our example firmware also includes a custom command now for reference: www.ti.com/.../slac691
  • 0 in reply to Ralph Jacobi
    Intellectual 525 points

    Hello Ralph,

    Thanks for the answer. I'm aware about commands patching. As far as I got it right, this way the processing and dispatching of the 15693 commands is done by the ROM and then the control is given to a user provided callbacks.

    Am I correct that the actual RF13M hardware module can be fully controlled by the user code and not the ROM code -- I mean, FIFO buffer management, interrupt handling etc? I am currently unable to check that because MSP-FET is still on the way.

    BR,

    Oleg

  • 0 in reply to Oleg Tcaregorodtcev
    TI__Guru*** 128255 points
    Hello Oleg,

    You are right that the ROM controls the RF13M hardware module still, but using custom commands will have the code check your custom command first before processing the ROM stack ISO15693 commands. This is why adding too many commands can affect your response time as each command is checked one by one and then once all are checked the ROM stack begins to process it's own list.

    This is the best that can be offered, if that isn't suitable for your application then you may need to look at other devices. The custom command feature is only intended to offer a few unique commands to amplify systems, not to replace the whole ISO15693 stack.
  • 0 in reply to Ralph Jacobi
    Intellectual 525 points
    Hello Ralph,

    Please answer a couple more questions:

    1. What is the actual meaning of the bit 6 (NFCBridgeDisable) in register 0xF867? Does it instruct ROM code to do/not to do smth?

    2. Excerpt from NFC Only Project NDEF Support, patch.c:
    If eUSCI host controller portion is needed along with the RF functionality, the default project must be used. That is NFC cannot be supported in that application (because the I2C/SPI host controller control registers are in the same place that the NFC file needs to be).

    Does it only refer to the usage of I2C/SPI dispatching by the ROM code? If I override interrupt handlers and re-implement this as well, shouldn't be an issue, right?

    BR,
    Oleg
  • 0 in reply to Oleg Tcaregorodtcev
    TI__Guru*** 128255 points
    Hello Oleg,

    1) NFC Bridge functionality was something that was included in the device on design, but to be frank and transparent, ultimately served no real benefit and no customer ever desired it's use. I think most of that has been taken out of the Firmware's User Guide as it was decided it would not be supported.

    2) Correct, it is only for the ROM support that exists via the virtual registers The NDEF project is an example to allow for NDEF messages to be read in an NFC-compliant manner (different from ISO15693 compliant). To do so, the virtual registers need to be used for NDEF information. This means that when the host controller is required for an NFC application, you would need to develop that code in FRAM. We have no examples for this however.