Talking about sensor error and ADC error and the advantages of correcting such errors

As Internet of Things (IoT) networks become more complex, so does edge processing at IoT endpoints. As a result, existing endpoints may need to be upgraded with new systems whose microcontrollers require faster clock speeds, larger memory, and more powerful processor cores.

Author: Bill Giovino

As Internet of Things (IoT) networks grow in complexity, so does edge processing at IoT endpoints. As a result, existing endpoints may need to be upgraded with new systems whose microcontrollers require faster clock speeds, larger memory, and more powerful processor cores.

In addition, high-precision sensors and analog-to-digital converters (ADCs) may be required, and these devices may also require periodic calibration. For linearity errors, it is easily compensated using the formula. However, there is no fixed pattern of deviation between the nonlinear error and the sensor reading, so it cannot simply be compensated for mathematically. Often, the easiest way to compensate for firmware non-linearity errors is to use a data lookup table to store the required correction data in memory.

This article will briefly introduce sensor error and ADC error, and discuss the advantages of using a data lookup table to correct for such errors. In addition, this article will explain how to use ON semiconductor‘s external LE25S161PCTXG Serial Peripheral Interface (SPI) flash chip to implement a practical, cost-effective data flash lookup table in a system based on STMicroelectronics’ STM32L496VG microcontroller.

sensor error

For sensors that can detect analog quantities such as temperature, pressure, and voltage, nonlinear errors may exist. During the project development phase, it is especially important to test the sensor against an accurate benchmark and compare the sensor digital output to the benchmark value. This allows developers to determine at an early stage whether there are any deviations from the sensor reference value and whether these deviations are acceptable in terms of application requirements. The developer can then decide whether it is necessary to compensate for any deviations, and if so, whether the deviations should be compensated in hardware or firmware.

Some sensor errors may be predictable linear errors. This type of error compensation is as simple as adding or subtracting a constant to the sensor output. Sometimes this type of error may vary with sensor range. For example, from zero to one-third of the range, a constant may need to be added; from one-third to one-half of the range, a different constant may be required.

These errors are predictable and obviously easy to correct, however, deviations from accurate readings may change over time. In addition, new errors may arise in the future due to sensor exposure to extreme temperatures, high ambient humidity, or sensor aging. Whether these errors need to be corrected always depends on the application. It may be necessary to test the system under extreme temperature, pressure and humidity conditions to determine sensor performance. Applications such as automotive, military, and certain industrial systems require detection of these environments. However, with many new IoT endpoints now extending beyond sensor applications, sensor testing may become a new requirement.

Like analog sensors, common microcontroller analog peripherals such as ADCs may require periodic in-system calibration. ADC errors are not always predictable, and even if the initial error can be corrected using an algorithm, the error may change over time and may become impossible to easily correct by the algorithm. This can cause the system to no longer continue to operate with the required accuracy, resulting in high replacement costs.

Advantages of Analog Sensor Error Correction Using Data Lookup Tables

Data lookup tables are a practical and efficient way to quickly perform common calculations, complex calculations such as trigonometric functions, or simple calculations such as bit-reversal of bytes or Gray code conversion. Bit-reversing bytes using a 256-byte lookup table is significantly faster than performing bit-reversing in firmware. It is safe to store this lookup table in program or data flash because it has a small footprint and never needs to be changed.

In addition, the use of data look-up tables for storing sensor data calibrations is also a proven method. Microcontroller analog peripherals like the built-in ADC may require periodic calibration in exactly the same way as analog sensor calibration. ADCs in most microcontrollers are accurate to ±2 or ±3 least significant bits (LSBs). While this is sufficient for most applications, regular calibration of the ADC is important for systems that require high accuracy.

A fragment of the calibration look-up table for correcting 24-bit data might be as shown in Table 1.

sensor reading sensor correction value

: :
01 AB 24h 00 01 AB 21h
01 AB 25h 00 01 AB 22h
01 AB 26h 00 01 AB 24h
: :

Table 1: Example snippet of a data lookup table for 24-bit calibration data. The raw input value is the source reading that requires error correction. The raw value is then used as a 24-bit address to find the corresponding 32-bit corrected value, where the most significant byte is always 00h. (Table data source: Digi-Key Electronics)

In this example, the raw input value is the source reading that requires error correction. The raw value is then used as a 24-bit address to find the corresponding 32-bit corrected value, where the most significant byte is always 00h. If the lookup table does not start at address zero, an offset can be added to the original input value.

Before deciding where to store the lookup table, it is important to determine the size of the lookup table and whether it needs to be rewritten. Both are important. If the rewrite is never needed, the lookup table can be stored in the microcontroller’s available on-chip flash memory. But if the sensor needs to be periodically recalibrated, then the internal flash memory is rewritten, which requires erasing the entire flash memory sector where the data sheet resides and reprogramming.

If this flash sector shares space with program memory, the code may need to be recompiled. Even if the lookup table is located in a separate dedicated sector, memory requirements may change or need to be extended in the future, causing part of the lookup table sector space to be repurposed for other code. This complicates field sensor calibration, and requires downloading recompiled code over the network, making it impossible for IoT endpoints to self-calibrate independently. The problem is further complicated if multiple sensors are involved.

Using a large look-up table (eg 16,777,216 entries) for 24-bit digital data calibration is impractical or even impossible for on-chip Flash program memory. If every other entry is stored and the missing entry is inserted into the existing table data, the lookup table size can be halved. This approach incurs a small performance penalty, perhaps ±1 LSB of accuracy. However, even a lookup table with 8,388,608 entries cannot be stored in internal flash memory.

In microcontroller-based systems, the best solution for using such large data lookup tables is to use external flash memory. This provides an easy way to add megabytes of lookup tables without sacrificing internal Flash program memory. At the same time, the system can easily rewrite the look-up table without affecting the microcontroller’s internal flash memory.

For high-performance systems, adding external parallel flash to expand program and data memory is a common approach. However, this requires the microcontroller to have an external data bus. Additional address and data buses and required control signals require 36 or more pins on the microcontroller. This requirement limits the microcontrollers available to the application. In addition, the external bus takes up more printed circuit board space and may increase the electromagnetic interference (EMI) of the system.

For most systems, the best solution is to use external serial data flash. This type of flash uses the Serial Peripheral Interface (SPI) for data transfer and requires only four microcontroller pins.

ON Semiconductor’s LE25S161PCTXG is a typical example of such a flash memory device. This 16 Mbit serial flash device supports an SPI clock of 70 MHz. At the same time, it also supports dual-channel SPI mode, and the data transmission speed can reach up to 140 Mb/s. Internal status registers can be used to configure the device for read, write, and low-power modes.

The SPI signals of the LE25S161PCTXG are typically used for clock, data, and chip select (Figure 1). It also has two extra pins. WP is an active-low write-protect signal that prevents writes to the device’s status register. This can be used to prevent unauthorized rewriting of the device by low priority firmware tasks. HOLD pauses an ongoing data transfer. This feature is useful if the microcontroller has to perform an interrupt during a data transfer. Data transfer will be suspended until the interrupt is processed, and then resume the transfer from where it left off.

Figure 1: ON Semiconductor’s LE25S161PCTXG serial flash is available in an 8-pin UDFN package with a very small 3 x 4 mm footprint and provides the usual SPI signals for clock, data, and chip select. (Image credit: ON Semiconductor)

The easiest way to read a simple two-column lookup table stored in this device is to take the sensor reading, add the memory offset, and read the memory content corresponding to that address location. The memory content corresponding to this address represents the sensor calibration reading.

High-performance IoT endpoints require faster clock speeds, better processor performance, and more flexible SPI. For these applications, STMicroelectronics offers the STM32L4 high-performance microcontroller family. For example, the STM32L496VG is a microcontroller in the STM32L4 product family that operates at 80 MHz and has an Arm® Cortex®-M4 core with a floating point unit (FPU). The device features 8 Mbits of flash and 320 KB of SRAM and supports a 1.71 to 3.6 V operating voltage, overlapping the 1.65 to 1.95 V operating voltage of ON Semiconductor’s LE25S161PCTXG.

The STM32L496VG comes with a full set of peripherals suitable for high-performance IoT endpoints, including a real-time clock (RTC) with calendar function, three ADCs with a sampling rate of 5 MSPS Controller Area Network (CAN) interface and four I2C interfaces (Figure 2). In addition, there are three standard SPI interfaces and one quad SPI interface.

Figure 2: The STM32L496 microcontroller is based on an 80 MHz Arm Cortex-M4 with FPU, with a full set of peripherals including a 40 MHz quad SPI interface. (Image credit: STMicroelectronics)

The STM32L496G-DISCO development board provides strong support for the development of the STM32L496VG (Figure 3). This IoT terminal development board is fully functional, including a stereo Micro Electro Mechanical System (MEMS) microphone, 8-bit camera connector, eight LEDs, a four-way joystick, and a 240 x 240 pixel color LCD. Connector pins can be used as ADC inputs, quad SPI pins, and most I/Os.

Figure 3: The STM32L496G-DISCO development board provides a complete evaluation environment for ST32L496VG hardware and firmware development. (Image credit: STMicroelectronics)

The quad-channel SPI of the STM32L496VG supports a maximum SPI clock of 40 MHz, as well as standard and memory-mapped SPI modes. Quad SPI supports dual SPI mode with a maximum data transfer rate of 80 Mb/s.

STMicroelectronics’ Quad SPI enables quick connection to serial data flash devices. In standard SPI mode, all operations are performed using the SPI registers. Data is transferred by reading and writing the SPI data register. An interrupt is generated when data is received. This is the same as the three standard SPI operating modes of the STM32L496VG. Standard SPI mode supports single, dual and quad data transfer. ON Semiconductor’s LE25S161 supports single- and dual-channel SPI modes, and easily interfaces with the STM32L496VG in dual-channel SPI mode (Figure 4).

Figure 4: In dual-channel SPI mode, STMicroelectronics’ STM32L496VG quad-channel SPI serial port can be connected to ON Semiconductor’s LE25S161, SIO0 and SIO1 can realize bidirectional data transfer, SCLK can reach 40 MHz, and the rate is 80 Mb/s. (Image credit: Digi-Key Electronics)

Implementing a data look-up table is simple with a selection of ON Semiconductor and STMicroelectronics components. The quad SPI also has FIFOs that can be used for bulk data transfers. However, if the lookup table only needs to access one memory location at a time, then disabling the FIFO is recommended as this feature is not required and may even cause unnecessary delays.

Quad SPI with Memory Mapped Mode

Quad SPI also supports a memory-mapped mode that maps external serial flash into the microcontroller’s program or data memory space, allowing microcontroller firmware to access external SPI flash almost as if it were accessing the microcontroller’s internal memory, This in turn makes quad SPI operation transparent to firmware.

If the look-up table is not frequently accessed, the advantage of implementing the look-up table in memory-mapped mode compared to standard SPI mode may not be significant at all, just to simplify the application firmware. However, if the application needs to be interrupted frequently, the SPI transfer may be repeatedly suspended to handle the interrupt. The situation can become quite complicated if one quad SPI seek operation interrupts another seek operation.

Compared to standard SPI mode, memory-mapped mode can handle applications with frequent lookup table accesses and high interrupt rates more quickly and efficiently. This approach simplifies firmware, prevents problems caused by simultaneous accesses of four-channel SPIs with different priorities, and reduces interrupt conflicts.

However, implementing a memory-mapped lookup table has the disadvantage of potentially polluting the data cache. Although the STM32L496 does not have a data cache, some microcontrollers for high-performance real-time applications have this feature. However, accessing the lookup table will most likely result in a cache miss. Because for most applications it is rarely necessary to access the same location of a lookup table twice in the same thread or subroutine, the lookup table data does not need to be cached in the original design, and caching data may cause important data removed from the data cache. Although this problem occurs only with extremely high performance applications, it is these high performance applications that require data caching in the first place.

There are few solutions to lookup table data cache pollution. If the hardware allows, the region where the lookup table is located can be marked as non-cacheable. Another solution is to disable the data cache before accessing the lookup table and then re-enable it after. This approach is acceptable if the performance penalty of cache switching (enable/disable) is acceptable. Some data caches support architecture-specific cache control directives that prevent cache pollution. When looking for the best way to configure data caching for a particular application, it is important to benchmark your system performance.

The serial flash should be arranged on the printed circuit board, and the trace length should not exceed 120 mm. To avoid interference, the SPI clock signal path should be at least three times the width of the printed circuit board traces and away from other signals. The distance between the two bidirectional data signal lines should be kept within 10 mm to avoid skew.


In IoT endpoints, external SPI flash devices are an efficient solution to implement large data lookup tables. This approach enables easy in-system reprogramming and upgrades and minimizes microcontroller resource usage.

The Links:   SKKT57/16E EL640.480-A3 IGBT-SUPPLIER