Figure 1: Memory organization (map) of SST26VF064B – consists of eight 8 KB blocks, two 32 KB blocks and 126 64 KB blocks.
Internet of Things (IoT) devices are being introduced into the market at a rapid pace, from home appliances to medical devices, to cars; manufacturers must stay ahead of their competitors with new innovations and the flexibility to adopt or integrate new technologies. Designers must build flexibility into their products to meet the evolving IoT ecosystem as new functionalities and regulations are adopted.
Firmware updates not only allow customization during initial deployment at a customer site, but also enable new functions/features to be added after a product has been in the field or allows fixing of any firmware issues during usage. Non-volatile memory devices such as NOR Flash are commonly used as a firmware code storage medium due to its re-programmability and reliability.
By re-writing a portion of the device firmware code, residing in the non-volatile memory used in the device, manufacturers can easily update device capabilities. When looking to update firmware there are three things to consider: What/how much code to update, how often to update and the time it will take (speed) to perform the update.
What/how much firmware code to update
What and how much firmware code to update must be considered during the initial design phase of the IoT device. The updatable portion of the firmware must be stored in separate area of the NOR Flash device than the non-updatable portion. Updating any piece of NOR Flash starts with first erasing that portion of the memory and then programming new information in that portion.
Figure 2: Organizing the memory in non-updatable portions (example: boot code) and updatable portions (Examples: code for functions/features, image files and parameter variables).
NOR Flash is organized in portions which are called sectors and blocks of different sizes. NOR Flash devices, such as SST’s SuperFlash® technology part number SST26VF064B (64 Mbit or 64Mb), are organized in uniform 4 KB sectors which can individually be erased and reprogrammed (4 KB = 4 * 1024 * 8bits = 32,762 bits). It is also organized in larger 8 KB, 32 KB and 64 KB blocks which can also be individually erased.
Thus, one 8 KB block has two sectors, one 32 KB block has eight sectors and one 64 KB block has 16 sectors. Figure 1 shows the memory organization of SST26VF064B in 8 KB/32 KB /64 KB blocks. Each block can also be individually protected.
Prior to performing any update to any portion of the Flash, the blocks in that portion must be unprotected to allow for erasing and programming. After completing the update, it is prudent to again protect those blocks to prevent any inadvertent writing or erasing of those areas.
Table 1: Sequence of Flash command instructions to update 1 Mb/2 Mb/4 Mb of memory.
The updatable portion of the firmware must be organized in sectors and blocks in such a manner that there is enough flexibility to allow both limited and maximum feature/function updates. Since the speed of doing updates is determined by the number of sectors and blocks that need to erased and re-programmed, it is better to think of speed and flexibility together when organizing the updatable portion of the firmware.
Table 2: Program and erase times for SST26VF064B and conventional Flash.
Figure 2 shows an example of organizing the memory into updatable and non-updatable portions. Non-updatable portions such as boot code are stored in protected regions. Updatable portions of firmware such as features/functions are divided into smaller blocks or larger blocks based on flexibility requirements.
Updatable image files are stored in larger blocks and updatable variables/parameters are stored in smaller blocks.
How often to update
The main limitation to how often you may want to update firmware is the endurance limitation of the memory used in an application. SuperFlash technology memory such as SST26VF064B has 100,000 endurance cycles which means that each sector can be programmed and erased 100,000 times.
Table 3: Amount of time required to update 1 Mb/2 Mb/4 Mb of SuperFlash technology memory.
The possibility of updating firmware 100,000 times sounds like plenty; however, many IoT devices collect data and store the information in the NOR flash during usage so this must be considered when calculating maximum endurance cycle limitations. It is important to allocate sufficient sectors in the memory to account for endurance.
Let me explain with an example: Suppose the IoT device is collecting and storing 16 bytes of information and the information is expected to be collected and stored 100 million times during the life of the product.
The number of sectors that should be allocated can be calculated as follows:
1 sector = 4 KB
Assume all the address locations in the sector are used to store information, 16 bytes of data at a time, and are written to a new address location until the end of the sector is reached (e.g. 0x0000-0x000F then 0x0010-0x001F then 0x0020-0x002F, etc.)
Since 4 KB/16 bytes = 256, that is the number of times storage can be written before reaching capacity in the sector and erasing any data in the sector
Endurance limit of 1 sector = 100,000 cycles
Thus, if 1 sector can be written 256 times for 100,000 cycles, the data can be collected and stored 25,600,000 times
If an application requires data be collected and stored 100 million times, the number of sectors to allocate is calculated as 100,000,000/25,600,000=3.9. Therefore, in this example, it is necessary to allocate 4 sectors to store 16 bytes of data for the life of the application.
Table 4: Amount of time required to update 1 Mb/2 Mb/4 Mb of Conventional Flash memory.
IoT device engineers need to do similar calculations to allocate sufficient sectors and blocks for data logging parameters so as not to breach the endurance limit of their NOR Flash device.
Speed of Updates
The speed of an update can be calculated based on the number of blocks and sectors that need to be erased and reprogrammed. Suppose it is necessary to reprogram 1 Mb, 2 Mb or 4 Mb of firmware code/data which is stored in several 64 KB blocks in the SST26VF064B. The code/data can be comprised of firmware code, image files or other code that needs to be updated. Doing the update involves performing a sequence of command instructions to Flash.
The sequence would start with unprotecting the blocks of memory, erasing those blocks, programming those blocks with updated data/code and re-protecting those blocks of memory. For the SST26VF064B, the required sequence of instructions for updating 1 Mb/2 Mb/4 Mb of memory is shown in Table 1. From Table 1 it is evident that the two most significant times are erase time and program time. SST26VF064B uses SuperFlash technology which provides excellent erase performance. A comparison of erase and program performance for SuperFlash technology vs. conventional Flash is shown in Table 2. The vastly superior erase performance provided by SuperFlash technology as compared to conventional Flash is immensely useful for reducing update time.
SST26VF064B supports a maximum clock frequency of 104 MHz, maximum sector erase time of 25 ms, maximum block erase time of 25 ms and maximum page program time of 1.5 ms. Also a 12 ns delay (CE high time) is required between each command instruction to Flash memory operating at a clock frequency of 104 MHz. Using the sequence of commands shown in Table 1 along with knowledge of the program and erase times, the calculation for the amount of time required to update 1 Mb/2 Mb/4 Mb of Super Flash technology memory and conventional Flash memory is shown in Tables 3 and Table 4, respectively. Such calculations must be done by IoT device engineers to estimate the speed of doing updates with the aim of minimizing the IoT device downtimes during updates.
Conclusion
IoT device design engineers need to provide flexibility to update the application code and data. What and how much code to update, how often to update and the speed of updates are issues that need to be addressed while designing an IoT device. The selection of non-volatile memory impacts these issues and plays a critical role in calculating the timing and speed of code updates.
Author: Hardik Patel,
Sr. Applications Engineer
Microchip Technology | https://www.microchip.com
