Preparing Movesense Sensor Firmware for Production

Introduction

The Movesense sensor is a sensor platform that allows OEM customer to implement their own solutions quickly and easily and to cut the time to market. However, since the Movesense sensor gives companies the power to implement their own customer sensor firmware, they also need to have knowledge on things that their firmware affects outside their own customers. For customers that opt to use “productable” Movesense sample apps instead (such as our “Default firmware”) the requirements are less strict, it is still good idea to know the rest of the details. In short, this document tries to explain and list the basic requirements that the OEM customers need to fulfill when making volume orders of Movesense sensors.

From factory to customers

When the Movesense sensor is manufactured “in bulk” there are many steps and details that may not be obvious. They however pose a set of requirements that must be fulfilled for the process to be successful.

Production Line

In the factory production line, the Movesense sensor hardware is first programmed with our internal production firmware. This firmware allows the production line equipment to interact with the sensor, testing all the hardware and programming necessary data to it such as product information.

When the sensor has passed all the test steps the firmware chosen by the customer is programmed on it. To program the firmware, a “hex” file format is used. Depending on the base Movesense framework version used (1.9.x or 2.x series) the file used is different. For 1.9.x the firmware is typically provided as three separate hex-files (bootloader.hex, s132_nrf52_4.0.5_softdevice.hex and Movesense_with_settings.hex). For newer 2.x series firmwares the build system combines all the necessary data into Movesense_combined.hex-file which is produced by the firmware build process.

After the firmware is programmed, the sensor is set to “power off mode with stud contact wakeup”. This internal power-off state is a one-time power-off state to guarantee that the sensor is in power off when leaving the product line. However, it is possible that further activity such as packaging or quality control steps wake up the sensor from this power off state.

After the power off, the sensors are packaged in the packaging chosen by the customer and prepared for the shipping.

Movesense Default Firmware From BitBucket

As said, at the time of manufacturing, the firmware version chosen by the customer is programmed to the Movesense sensors. If the customer is using Movesense Default Firmware to test and develop their application, it is important that they are aware of the firmware and the version they are using. Multiple Movesense sample firmware versions, including simple demos, such as “Blinky”, are available at Bitbucket.

All the Default Firmware versions are located in default_firmware -folder.

When opening the Default Firmware folder, only the latest Default Firmware version is visible. Older firmware versions are found under master -button.

Before starting to manufacture OEM sensors, each customer needs to define and provide the exact firmware to be programmed to the sensors. If the Default Firmware is desired, this can be downloaded from the Movesense Bitbucket in “.hex” file format and sent to the Movesense Team. OEM Customers are responsible for verifying and testing the suitability of the chosen firmware to the customer specific use case, and once happy, for providing the desired firmware version to Movesense for pre-programming into customer specific OEM sensors.

Movesense programs the sensors on the production line, using the firmware provided by the customer, but Movesense is not able to verify which firmware version is suitable for each customer specific use case – this verification is on responsibility of each OEM customer. However, the Movesense team is happy to help, if guidance is needed.

In testing and development phase the sensor firmware can be updated by a smartphone application or a programming jig (purchased from Movesense.com/shop.

Please find more detailed instructions here: Step-by-step guide.

Shipping

The sensors are shipped first to our intermediate quality control and forwarded from there to their final destination around the world using the agreed-on shipping methods. Since most shipping methods include air cargo, the IATA rules for air freight also apply. The most important of those is the requirement to not to use radio transmitters during the flight. To comply with the requirement, it is necessary to implement a “shipping mode” in the custom firmware unless the firmware is such that it automatically goes to “non-transmitting” mode like Movesense Default firmware.

Shipping mode in firmware

If the sensor firmware is meant to stay powered on even without Bluetooth connection, the easiest way to implement the shipping mode is:

  1. When the user is first time taking sensor into use (real mobile connection from your own app), write a piece of information in the sensors EEPROM memory. A small area of EEPROM can be dedicated for this kind of information using the DATALOGGER_MEMORY_AREA -macro.

  2. In the bootup, check the EEPROM content written in "1" to see if sensor was taken into use. If the sensor was not taken into use:

    • wait for a while (1-2 minutes), in case mobile app makes a connection.
      • If connection was made, see "1." above
      • If there was no connection (or the connection did not result start of operations), set wakeup to stud contact using /Component/MAX30004 -API and shutdown the sensor. For an example, see hr_wakeup_app in movesense-device-lib/samples.

Firmware update (DFU) on the field

When the sensor is in its final use, it may need to be updated to a new firmware. The firmware update should be integrated as a part of your own mobile software so that the process is as easy as possible for the final user. It is very important to test the DFU functionality of each custom firmware version before it is sent to customers for updating existing sensors or sent to be programmed on the production line to the new sensors.

The minimum list of tests that need to be performed for each new firmware:

Information for Movesense

The following information must be provided when making a bulk OEM order of Movesense sensors:

Information Description
Firmware file(s) Either Movesense_with_settings.hex (Movesense 1.9.x) or Movesense_combined.hex file. Preferably named: CompanyAppName_FW_AppVersion_Date.hex (“SuperTzap_FW_1.2.3_2022-10-11.hex”)
Product Name Name of the product that is returned by /Info -service. This string is used as a basis of BLE advertising device name (first 9 characters). Example: “SuperTzap”.
App Name Exactly as written in the App.cpp
App Company Exactly as written in the App.cpp
App Version Exactly as written in the App.cpp
Confirmation of shipping mode “Yes, shipping mode has been implemented” / “Shipping mode is not needed (goes to sleep in normal operation)”
Movesense framework version As reported by the /Info -service. (e.g. “2.1.1”)