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.

CC3220SF-LAUNCHXL: Wi-Fi provisioning over NFC - RF430CL330H

Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: RF430CL330H

Hi,

Currently I am using an AWS-IOT MQTT demo example code to communicate with the AWS-Server.

Part name : CC3220SF-LAUNCHXL- Launchpad Rev-A
SDK: SimpleLink_CC32xx v2_10_00_04


As part of the device Wi-Fi provisioning process, the current application supports Local Ping and Cloud confirmation as well.

Now, I want to integrate Wi-Fi provisioning over NFC

Please give some clarifications/suggestions for below mentioned points to use RF430CL330H - NFC module to integrate.


1. By using NFC Provisioning also we can achieve Local / Cloud ping confirmation same as normal provisioning?

2. RF430CL330H NFC - Module Specific queries
        A) Please let me know the approximate RAM usage for the NFC Plug-in.

        B) Is this NFC software stack certified as per NFC standards?

       C) As the device operates over the battery, what will be the approximate power consumption?


3. I am following following example code to integrate NFC-Provisioning (Wi-Fi NFC Provisioning example). By default What NFC mode which supports? (Card Emulation, Peer to Peer or Reader/ Writer mode)?


4. As the normal Provisioning process supports HTTP communication, I am able to GET/POST (Bi-directional communication) between mobile app and Device for exchanging certificates (~3KB size of the  data). If I use NFC Wi-Fi provisioning I can achieve the same bi-directional communication?
   
   
Regards,
Suresh   

  • Hi Suresh,

    I'll answer the wi-fi related questions (then forward to NFC experts to answer the rest):

    1. The NFC provisioning in this example only handles the network credentials reception (no verification of the connection is performed).

    Once the new profile is set (based on the data from the NFC Tag) - it is the application responsibility to check that the new settings works (e.g. through local/cloud ping test). The profile can be deleted and the provisioning can be restarted if the test fails (this is not currently supported by the example).

    3. In the example the NFC  is used as a tag (card emulation).

    4. The NFC provisioning can work in parallel to a regular SimpleLink provisioning (it will stop the SimpleLink provisioning and add the profile if NFC event will come). If you are asking in general about HTTP communication (not related to provisioning), then of course - the NFC provisionig is just about the L2 (wi-fi) connection to the access point.

    br,

    Kobi

  • Hi Suresh,

    I will answer the RF430CL330H related questions.

    A)

    The RF430CL330H handles the NFC communication and provides a NDEF message to the reader. The host has to do some register settings vi SPI or I2C and to load the NDEF message, that should be provided to the reader, into the RF430CL330H SRAM, which can be up to 3kB. This means the code needed from the host can be very small. Our code examples are in the 1k to 2k range for the code memory.

     B)

    The device is ISO14443B compliant and tested as NFC Tag Type 4.

    C)

    Please see the datasheet chapter 4.5 for the supply currents in different modes:

    https://www.ti.com/lit/ds/slas916c/slas916c.pdf?

    In addition the FAQ contains a lot of useful information:

    https://www.ti.com/lit/pdf/sloa244

    A document is available which describes Bluetooth Pairing with NFC which is maybe also helpful:

    https://www.ti.com/lit/pdf/sloa187

    Best Regards,

    Helfried

  • Hi Kobi,

    Thanks for your reply,

    Regarding question no 4:

    I wanted avoid complete Wi-Fi provisioning process along with the HTTP communication.

    As this is Card Emulation mode Is it possible to transfer and receive (2 way communication) ~3 KB of certificate data exchange over NFC?

    Regards,

    Suresh

  • Hi Helfried,

    Thanks for your response, I got more clarification.

    I got the supply current spec, As I am using battery operated device what will be the idle device current consumption? (When NFC is not performing any Read/Write  operation).

    Regards,

    Suresh

  • Hi Suresh,

    The NFC provisioning was not meant for enterprise network, so the certificate wasn't needed.

    I believe the code can be updated to receive other types of (proprietary) NDEF messages that can include certificates.

    I'm not sure about the size limitations on the NFC side. Maybe Helfried can comment on this.

    Br,

    Kobi 

  • Hi Suresh,

    the lowest possible current would be the ICC(standby) which is typ. 10µA but then RF is disabled (tag will not react to reader). With RF enabled it is the ICC(RF_enabled) with typ. 40µA.

    Best Regards,

    Helfried

  • Hi Helfried,

    Thanks again for your support.

    Application needs to exchange approx. ~3kb of certificate (Bi directional way) for this case NFC- NDEF messaging can support?. Can you comment on below lines.

    I believe the code can be updated to receive other types of (proprietary) NDEF messages that can include certificates.

    I'm not sure about the size limitations on the NFC side. Maybe Helfried can comment on this.

    Please let me know, Any sleep mode/wakeup signal NFC module supports.

    Regards,

    Suresh

  • Hi Suresh,

    the RF430CL330H has a 3k byte SRAM for the NDEF message. If your certificate fits into that space it should be no problem.

    In the Inactive and Standby mode the RF is disabled and a reader can not wakeup the device. In the RF_enabled mode the INTO pin is set depending on the settings in the Interrupt Enable Register.

    Best Regards,

    Helfried

  • Hi Helfried,

    As you mentioned, 10µA - 40µA power consumption for the tag (Card emulation mode)?

    From this Example, if the tag is passive, it shouldn't consume any power, because mobile will be the active reader.

    Please explain more on this concept.

    Regards,

    Suresh

  • Hi Suresh,

    the RF430CL330H holds to NDEF message in a SRAM which would need some power. When only the mobile phone powers the RF430CL330H then after power-up the NDEF message must be loaded from the host. In fact it is possible to create a complete passive system like the one in the following application note:

    https://www.ti.com/lit/ug/tidu378a/tidu378a.pdf

    Best Regards,

    Helfried

  • Hi Helfried thanks for your continuous support,

    In the Inactive and Standby mode the RF is disabled and a reader can not wakeup the device. In the RF_enabled mode the INTO pin is set depending on the settings in the Interrupt Enable Register.

    Since it is possible to configure that tag into complete passive as suggested (RF will be active when it is sourced from mobile phone power).

    Since RF is active, is it possible now to wakeup the host controller using an INTO.

    If it is not possible, please suggest which mode I can make use of INTO wakeup of host controller when it is in Hibernate mode.

    Regards,

    Suresh

  • Hi Suresh,

    using the INTO pin will not work, because the function of this pin needs to be configured. By default, after reset the INTO pin is high-z. You have to detect if a RF filed is present and then wake up your processor. In the passive application example tidu378a the power for the processor is take from the resonance circuit with two diodes (chapter 4.3) which can be used in your case as RF detection.

    Best Regards,

    Helfried