• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 781 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Can my project be done with RF430CL331H? :)

kazola
Guru 18595 points
Other Parts Discussed in Thread: RF430CL330H, RF430CL331H, RF430FRL152H, MSP430G2553

Hi everybody!

I have developed a cool NFC energy harvesting project thanks to previous help from this forum, you are all great.

My current project is based on RF430CL330H. However, probably we will remove this chip since, because of a new requirement, we need a static tag UID every time and the RF430CL330H is changing it every time after POR :( It is sad after many hours of work but, anyway.

So, I was wondering:

  1. Does the new RF430CL331H have any mechanism to use a static tag UID?
  2. If the previous is not possible, maybe I could consider switching to RF430FRL152H if this one has a static UID and I can program it to return the state of pressed buttons attached to it and I can protect the NDEF content to be read-only (this was solved in the RF430CL33x because of not having persistent memory).

So! Please let me know your opinions about my design issues!

Have a really nice day from Barcelona.

  • 0
    TI__Mastermind 29105 points

    Hey Kazola,

    Is there no way to use the NDEF data to store a chosen ID + other status info?   This is how many customers handle Serial numbers, etc, when using Type B tags.  

    1.  The RF430CL331H, is the same as the RF430CL330H, with a Pseudo-Unique PICC Identifier (PUPI).  They both are random at power-up.  

    2. The FRL152H has a fixed UID.  You can lock the bytes so that NFC can't overwrite them, but there is no way to protect the bytes from the MCU side.  I'm not sure what your MCU is doing, but if you are just trying to measure some sensors, the FRL15x can probably handle this on it's own.  

    The FRL15x has the built in ability to read analog and digital sensors directly.  It can also be programmed and configured over the air.  

    Please share any follow up thoughts.

    Thanks,

    JD

  • 0 in reply to JD Crutchfield
    Guru 18595 points
    Hi ,

    mmmm for example, if you try to use an NFC tag to unlock your Android phone through SmartLock, you need a fixed UID. You cannot work with NDEF internals.

    I would like the NFC tag to return the state of an attached pressed button in its NDEF message. For example, the FRL152H should return an application record (ex: launch android calculator as I do with RF430CL330H) whenever I press button1, or return a simple "hello world" message whenever I press button2.

    I have done this with RF430CL330H and MSP430G2553, and it was fine because RF430CL330H has no EEPROM, I didn't worry about its NDEF content being modified by malicious users, since it is always freshly load from MSP430G2553 powered by harvesting from RF430CL330H.

    However, because of FRL152H having EEPROM, users may modify my FRL152H. Or maybe there is a way to configure FRL152H to only accept fresh new contents from MCU as I do with RF430CL330H?

    Please let me know.
  • 0 in reply to kazola
    TI__Expert 7820 points
    Kazalo, let me try to answer this.

    The RF430FRL15xH uses a different protocol for RF communication, the ISO/IEC 15693. This protocol allows for locking the entire user memory to prevent memory updates over RF. The memory can still be read however.

    Also the RF430FRL15xH also can be used with an external MCU such as in the RF430CL330H. However this is generally unnecessary, but there is ROM support for an I2C and SPI host controller.
  • 0 in reply to kazola
    TI__Mastermind 29105 points
    Hey Kazola,

    I was just talking with Alex, and the FRL152H does not currently support NDEF. It follows ISO15693 as he mentioned, but it doesn't currently have NDEF capability in the built in NFC stack. This may pose an issue for you.

    The FRL15x was designed as a NFC configurable sensor transceiver, which ideally works with custom readers or applications.

    We may not have exactly what you are needing.

    Thanks,
    JD
  • 0 in reply to JD Crutchfield
    Guru 18595 points

    Thanks anyway to both of you.

    It is a pleasure to exchange opinions with TI staff.

    Ok, then probably I will think a little more about our design.

    Maybe this is something you could add in the next RF430CL332H, the capability of choosing random UID or static UID depending on one GPIO to VCC or to GND ;)

    Have a nice day from Barcelona!