manufacturing.tex

\documentclass[main.tex]{subfiles}
 
\begin{document}
\chapterimage{band1.jpg}
\chapter{Manufacturing}

While building IoT products it is often the case that some unique information needs to be stored in each device. 

For example, in our journey so far, you might have realised that some cloud platforms have certificate based authentication, and we have embedded the device certificate within the firmware itself. This is fine when we are developing with a single device, but what do we do when we have to create hundreds of thousands of such devices? In this section this is what we will look at.

You might remember the NVS partitions that we discussed in Section \ref{sec:nvs_info}. This was used to store key-value pairs persistently into the flash. Because this is stored in the flash, this information was accessible even across device reboot events. Also remember that we implemented the \textit{Reset to Factory} action in Section \ref{sec:reset_to_factory} by erasing the contents of this NVS.

We can use the similar NVS partition for storing per-device unique keys. But we want that this unique information should not be erased across the \textit{Reset to Factory} events. This can be facilitated by creating another NVS partition that is primarily used for storing such unique factory-programmed information. Since this partition is programmed at the factory, we will use this NVS partition as a read-only partition, only referring to it to read the unique values that were configured for us.

Thus we can reuse the same concept to store factory unique information.

\section{Multiple NVS Partitions}\index{Multiple NVS Partitions}
We had looked at \textit{Flash Partitions} in Section \ref{sec:flash_partitions} while discussing firmware upgrades. In Section \ref{sec:updating_flash_partitions} we also looked at how the flash partitions can be modified. For this example, we will add this extra NVS partition that will store the unique factory settings, and call it \textit{fctry}.

You can check this by looking at the file \textit{7\_mfg/partitions.csv}.

\section{The Code}\index{The Code}
Now that this NVS partition is present, we can access it using the standard NVS APIs. The only thing though is that you need to instruct NVS to use this other NVS partition while performing its NVS operations. This can be done by initialising the NVS handle as follows:

\begin{minted}{c}
#define MFG_PARTITION_NAME "fctry"
/* Error checks removed for brevity */
nvs_handle fctry_handle;
nvs_flash_init_partition(MFG_PARTITION_NAME);
nvs_open_from_partition(MFG_PARTITION_NAME, “mfg_ns”,  
               NVS_READWRITE, &fctry_handle);
\end{minted}

Now the NVS get operations that are performed with the \textit{fctry\_handle} NVS handle will be result in reading data from this factory NVS partition. For example,

\begin{minted}{c}
nvs_get_str(fctry_handle, “serial_no”, buf, &buflen);
\end{minted}

So, we can now disable the code that embeds any certificates in the firmware itself, and instead, read them from the unique factory partition that is flashed for this device.

\section{Generating the Factory Data}\index{Generating the Factory Data}\label{sec:gen_factory_data}
Now we are good to go from the firmware perspective. But we still need to identify some mechanism for generating the factory data that will be written to the \textit{fctry} partition.

The utility \textit{idf/nvs\_flash/nvs\_partition\_generator/nvs\_partition\_gen.py} is used to generate an NVS image on the development host. This image can then be written to the flash into the location of the \textit{fctry} partition.

This utility accepts a CSV file, and generates the image of an NVS partition from it. This CSV file stores the information about the key-value pairs that will be part of the generated NVS partition. At a factory, hundreds of thousands of these NVS partition images will be generated, one per device being manufactured, and then written to the respective devices uniquely.

A sample CSV file, called \textit{mfg\_config.csv} is available in the app. Each of its lines contains the values for the variables that are unique at the factory.
Update them such that your unique settings are part of this CSV file.

The NVS partition can then be generated as:
\begin{minted}{bash}
$ python nvs_partition_gen.py mfg_config.csv my_mfg.bin
\end{minted}

The my\_mfg.bin file is the NVS partition data that can now be programmed into the device. You can use the following command to write this NVS partition to flash:
\begin{minted}{bash}
$ /path/to/idf/components/esptool_py/esptool/esptool.py -port /dev/cu.SLAB_USBtoUART write_flash 0x340000 device-164589345735.bin
\end{minted}

Now if you boot up your firmware, it will work exactly as the firmware in the previous Chapter. But in this case, the firmware image itself is independent of the unique settings per device. 

This allows you to create as many unique images as you want, and then flash them on the respective boards.

For more details about the unique factory partitions please refer to this link \url{https://medium.com/the-esp-journal/building-products-creating-unique-factory-data-images-3f642832a7a3}

\section{Progress So Far}\index{Journey So Far}
In this Chapter we looked at creating unique factory images per device, for contents that typically change across devices.

With this, we now have a fully functional, production-ready device firmware ready to ship out!

\end{document}