NHS31xx SW API
Production firmware

The firmware released in the SDK can be used as a starting point to develop your own production firmware application. Keep in mind that all demo applications are developed with demo usage in mind; your own production firmware application can do better. The demo firmware focuses on showcasing the functionality given a generic use case. Production firmware can make more specific choices, and will put a different focus on key behavior.
Below is an incomplete list of items where production firmware will likely deviate from the demo firmware as supplied via the SDK.

Warning
Be careful when considering any of the below. Be sure to test thoroughly and extensively.

Compression

The SDK includes a compress module, which is just an example of what can be done. Using your own use case, a specific compression can yield bigger advantages. Be sure to go through the ideas exposed in the slides available under <SDK>/docs/DataStorage.pdf

Validation

The demo firmware in the SDK includes a simple check on threshold excursions. A specific algorithm can provide a more useful check in real-world situations, but is likely also tied to a specific product. It will also depend on whether the IC is integrated in the primary or secondary packaging, and on the thermal resistance of the packaging and the product. Getting the validation right for your specific use case is seen as a differentiating factor for each customer.

Communication

The SDK includes a simple communication protocol (msg: Message Handler) built on top of standard compliant NDEF messages (ndeft2t: NDEF Type-2 Tag Message creator/parser Module). This provides maximum compatibility with all PC and mobile platforms, and easy extendability. To provide the best experience to any user, the available messages - commands and responses - are best extended and tailored to retrieve the desired information with the least effort from the tag reader.

  • remove the generation of TEXT records if you don't need them;
  • add or replace the generation of MIME records to precisely target your own use case.

Security

Security is not implemented in the demo firmware. Depending on your use case, you may want to add:

  • password protection - the msg module aides with this: see MSG_COMMAND_ACCEPT_CB
  • AES encryption. Combined with a communication scheme to establish trust such as ISO/IEC 29167-10:2017, this allows communication between tag and server using a phone as an untrusted transport medium.
  • Also possible, but very taxing, is encryption in software based on elliptic curves, for example, using an ECC key size of 192 bit. Doing this will most likely slow down your communication and affect your application logic.

Best is to start with the basics: be sure to store minimal information, and make a thorough analysis which security mechanism is warranted. And when access keys come into play, use the 16-byte unique chip ID (this is not the NFC ID) to make sure that different tags have different keys. Keep in mind that the IC is not a secure IC, i.e. there are no anti-tamper features in HW. Thanks to the HW design, it is possible to make a functionally secure product, as the firmware decides what the host app can access through NFC or any other interface.
Depending on your needs, different levels of security can be attained.

NFC readout

The demo firmware is quite slow when it comes to reading out all the captured temperature values. This is a consequence of our decision to develop a demo application which is as generic as possible. The current approach keeps the firmware as separate as possible from the host apps, and allows, for example, for isolated changes to the compression method employed.
Concretely, the temperature values from the temperature logger demo are uncompressed before copying in an NDEF message; plus, each temperature value occupies 2 full bytes during transport via NFC. By passing on the data compressed, and moving the uncompress logic to the host app:

  • additional space is freed in firmware, as the uncompress logic is removed.
  • a tight coupling is made between the specific implementation and configuration of the compression logic in firmware with opposite operations to be implemented in the host app. Changes made on one platform of this internal implementation require synchronization on the other platform.
  • readout requires less processing time, as the data can be copied unaltered from FLASH and EEPROM.
  • readout can now be done much faster. The estimated speed gain is 250%.

Optimizing System Clock

Most demo firmware applications increase the System Clock to 2MHz. This allows them to do more at startup, and still deliver an NDEF message in the NFC memory, in time before the tag reader starts reading the NFC memory. Power consumption is noticably larger during active periods because of this, and the battery voltage drop is a bit higher. Best would be to restructure the startup code, to allow a lower System Clock of 1 MHz or 500 kHz (the default). Setting the clock too low is a risk: if the NDEF message is not ready in time, communication with the APP running on the tag reader may be hampered.
Another optimization is to set the System Clock dynamically: lower the System Clock as much as possible, and temporarily increase the system clock whenever necessary. This needs to be done carefully, as changing the System Clock implies a re-initialization of a number of peripherals, such as the EEPROM HW block. Also, interrupts are then automatically handled on that low speed. For example, current consumption can be lowered by lowering the System Clock before entering Sleep or Deep Sleep mode. Tackling this in a reliable way suggests for a separate code block that can decide the optimal Sytem Clock speed, which keeps track of the affected HW blocks, maintains some form of history, and implements a re-entrant API.

Link-time optimization

The project settings in the SDK do not enable link-time optimization (-flto). Still, this makes a lot of sense, since it allows a lot more inlining of functions.

Be careful when enabling this: best is to enable this on a file-per-file basis, carefully testing every build. Be on the lookout for too agressive inlining, or for removal of variables (such as the interrupt vector table) that look useless from a pure SW point of view during the linking stage. Also, more recent GCC versions will produce more reliable results. The expected code size reduction is 8%.

GCC version

The supported IDE for firmware development is the LPCXPresso IDE v8.2.2. This IDE uses GCC version v5.4.1 for compiling and linking. By switching to a more recent GCC version, a modest gain in code size reduction can be obtained.
The demo firmware applications are all managed, i.e. the makefile is generated dynamically by the IDE. By looking at the build output log, a non-managed script can be made quickly and run using a more recent version of GCC. The expected code size reduction is 1-2%.

Taking a first temperature measurement

The current temperature logging demo firmware allows a user to configure a first wait time before measurements are made. This allows the user to configure and start measurements and bring the goods in a temperature controlled environment. The goods then have a small amount of time to acclimatize. A better approach may be to measure and store immediately, and to disregard the first x values for validation. This allows for some leniency when preparing the goods, but still captures extremities. The best approach - whether the final implementation makes use of time, temperature, a combination of both or includes a third parameter - is to be derived from your use case scenario.

Temperature measurements in an NFC field

The temperature sensor accurately reflects the current temperature of the IC. When an NFC field is present, the excess harvested energy will be dissipated as heat. Temperature measurements taken during this time will not reflect the temperature of the product the IC is attached to, resulting in a confusing temperature graph. To address this, the demo firmware already refrains from taking a temperature measurement while the NFC field is present (this behavior can be controlled using the define APP_NO_MEASUREMENT_IN_NFC_FIELD).
Even better would be to also refrain from taking a measurement for some period of time after the NFC field was removed, to allow the IC to reach the ambient temperature again. This period is dependent on the typical strength of the NFC field and the thermal resistance of the packaging around the IC.