How do I read NDEF messages > 512 bytes from NHS3100?

[madhus]

I need to read NDEF messages more than 512 bytes in size from the NHS3100 through NFC. I have a working application that can read NDEF messages less than 512 bytes, but it's not completely clear to me how to read more than the size of shared SRAM.

Does anyone have an example of how to do that?

[stevewald]

Thank you both for exploring this. You have given an answer to a problem I struggled with on and off all summer!

Steve

[driesmoors]

Hi,

The idea is to use the NFC memory as a 'transport' channel. To have the Cortex M0+ provide more than half a kilobyte of data to the tag reader, you need to generate multiple NDEF messages. The temperature logger demo application demonstrates how to do that, making use of bi-directional communication sent between phone and tag. Check in the SDK the demo application app_demo_dp_tlogger: the file msghandler.c will react on each incoming command and generate a corresponding response.

The execution flow here is:

• The phone writes an NDEF message in the NFC memory.
• The ARM reads the MIME records, interprets it and calls the appropriate handler function (in msghandler.c).
• That handler function creates a response, which is dumped as payload in a MIME record.
• The generate NDEF message is then copied back to the NFC memory, overwriting the data the phone has written.
• The phone reads out the same NFC memory, and parses the response.

This cycle then repeats until all data is transferred.

Also be sure to read the html documentation <SDK>/docs/communication.html.

Kind regards,
Dries.

[madhus]

Thanks Dries, I did look at that example and your description clarifies a lot of details.

The message exchange approach works well for Android devices, but as far as I know, the iPhone does not expose NFC write capability at this time. So I believe reading large messages is the only option with the iPhone.

I was thinking of two possible solutions:

1. Set BYPASS bit in the CFG register and place larger messages in EEPROM
2. Implement low level NFC protocol using NFC communication registers (SR, CMDIN, TARGET, LAST_ACCESS etc.)

I'm guessing option 1 will work, but the NHS3100 user manual says all NFC registers will be disabled in bypass mode, so you probably can't get interrupts. Also, it would be limited to EEPROM size, which is an improvement over shared RAM, but not ideal.

Option 2 sounds ideal, but I don't know how to implement it or if it's even possible. From the description of the NFC registers it appears to be possible, but I really don't know how to do that.

Any recommendation would be greatly appreciated.

[driesmoors]

Hi,

Option 1 is not an option as it makes it impossible for the ARM processor to access the NFC memory, both reading and writing.

Option 2 is not an option on iOS devices, as iOS 11 only exposes reading of NDEF messages. Low level NFC commands are not allowed, as is any writing be it NFC or NDEF.

The solution proposed in SDK is to rely on interrupts to know when a tag reader completes reading an NDEF message, and to have the ARM processor follow a 'script-like' sequence to generate new NDEF messages, which are copied to the NFC memory. This eliminates the need for the tag reader to write, but deprives him of any control in what he can read. Support for this has been added in SDK 11 onwards (NDEFT2T module, NDEFT2T_MSG_READ_CB diversity setting) and is implemented in the tlogger demo under the function GenerateNextAutomaticCommand.

Have a look at it.

Kind regards,
Dries.

[madhus]

OK, that helped considerably. I downloaded the latest SDK (11.1), built and ran the tlogger demo. It all works as you say with Android and iPhone. I had to configure it with Android first, but then it worked fine.

I looked at the GenerateNextAutomaticCommand() function in maintlogger.c and I think I generally understand how it works, but I am still a bit confused. GenerateNextAutomaticCommand() looks like a state machine to me, with sIndex as the current state. The code advances through each state when sMessageRead is true, bounces between states 2 and 3 to send multiple messages, and terminates in state 5 (4+1, or default case label). That all makes sense, but I can't find where the state machine is reset back to state 0 after reading all measurements. I see where sIndex  is set to 0 when sResetAutomaticCommandGeneration is true, but that appears to happen only once in InitApp() at startup.

What am I missing?

[driesmoors]

Hi,

Between two active periods the IC enter the Deep Power Down low-power mode. In this mode, SRAM is not preserved. Leaving Deep Power Down (due to a timer expiration, an NFC field detection or a toggle of the WAKE-UP pin) requires a full reset. InitApp() will have been called again when a new communication session starts.

An high level overview of the different power modes can be found in <SDK>/docs/PowerModes.pdf

For the current session, when the full state and all data is transferred, there is nothing left to do (according to the firmware). So it does nothing, just waiting for an incoming command (which will never happen with an iOS 11 device) or until the NFC field is removed.

Regards,
Dries.

[vrushali_b]

Hi Dries,

When NHS 3100 IC comes from deep power down mode, does the eeprom contents are retained? because I am writing some data in eeprom and puting it in DPD mode using Chip_PMU_PowerMode_EnterDeepPowerDown(), but after wakeup eeprom contents are not retrieved. 

Do you have in example about it?

[driesmoors]

Hi,

The EEPROM code snippet in the documentation (<SDK>/docs/firmware.html, then Modules > Drivers > eeprom: EEPROM driver) should do: EEPROM is non-volatile memory and its contents will survive Deep power down and Power-off modes.

If, after writing, the contents are not flushed, the data is only copied to cache, and never reaches the non-volatile portion of the EEPROM. Flushing is done by calling

Chip_EEPROM_Flush(NSS_EEPROM, true);

or

Chip_EEPROM_DeInit(NSS_EEPROM);

Possibly this is omitted in your code. Can you check?

Best,
Dries.

[madhus]

OK, that makes sense. I suspected there was some kind of side effect, but I couldn't pin it down.

Thanks for all your help!