Expert Discussion丨How to ensure the accuracy and integrity of the programmed data?

The most basic and important function of a programmer is to program data (source file) correctly and completely into the chip. But how do we understand the so-called ‘correctness and completeness’? It is generally believed that the simplest and ‘rough’ method is to read back the programmed data and compare it with the source file (verification). If they are ‘consistent’, it is considered that the programming process is correct and complete, and if they are ‘inconsistent’, it is considered that there is a problem with the programmer. However, things are far from that simple, and we should not understand ‘correctness and completeness’ so simply.

In order to discuss this issue, let us first clarify the following definitions:

Definition of source files, programming files and reading files

1.Source Files

The source file is usually generated by the customer using a compiler, and the file formats include HEX, BIN, S19, ocfg, etc. The data of the source file needs to be programmed into the chip.

2.Programming Files

The OPTEEQ programmer (taking SG400 as an example) will first convert the ‘source file’ into a ‘programming project file’ (suffix .opj) through the accompanying ‘programming management software’. This ‘programming project file’ is composed of a ‘programming file’ (bin file format) with a suffix of .opd and a ‘configuration file’ with a suffix of .sct.

3.Reading Files

Reading file refers to the file generated after the chip is read by the programmer after the programming is completed.

*The following figure helps you understand the definitions of the three files above:

The content of the reading file is inconsistent with the source file or the programming file?

Customers often read the chip content after programming and compare the read content with the source file to determine whether the programmed content is correct. Usually this method is effective, but in some cases, although the programming process is correct and complete, the content of the read file is inconsistent with the source file or the programmed file.

The inconsistency between the ‘source file’ and the ‘programming file’ may be caused by the following reasons:

• ‘Source file’ consists of multiple files

Sometimes, a ‘source file’ is composed of multiple files. When creating a project, the OPTEEQ programming management software will merge multiple source files into one ‘programming file’. During the merging process, if the file content overlaps (multiple source files contain the same address) or the address exceeds the chip’s available address range, data inconsistency may occur.

• Inconsistent filling data

During the merging process, some area data (according to the chip manual requirements) will be filled with 0x00 or 0xFF. When some chips do not specify the filling format, the ‘source file’ and ‘programming file’ may be inconsistent due to different filling values.

• There is an irreversible scenario

The process of converting ‘source file’ to ‘programming file’ may cause irreversible situations, such as virtual address, data overlap, data beyond the chip range, etc.

The inconsistency between ‘programming file’ and ‘reading file’ may be caused by the following reasons:

1.Dynamic data (such as serial number, etc.) is added during the programming process;

2.There are special areas in the chip (such as HSM area);

3.There are special registers in the chip;

4.After the chip is programmed, it will automatically run the program that was just programmed in after it is powered on again. This program is likely to modify the data in the storage unit. If you read the contents of the chip at this time, the read contents may not be consistent with the ‘programmed file’.

Therefore, even if there is no problem with the programming process, the ‘source file’, ‘programming file’ and ‘reading file’ are often inconsistent. So, how to verify the ‘correctness and integrity’ of the programming process?

There are generally three ways to verify programming

Checksum & CRC

Both Checksum and CRC are calculated by the chip after programming and put into a fixed register. The programmer ‘grabs’ this check value and compares it with the check value of the ‘programming file’ to determine whether the programmed data is correct. These two verification methods are highly reliable, with an error rate of almost 0.

**We also added the CRC value of the source file in the project to facilitate tracking

Read-back Check

If you want to ensure that the data is completely consistent, you can choose read-back check: read the data in the chip storage unit during the programming process (not after the programming is completed) and then compare it with the data in the ‘programming file’ one by one. We believe that this method has the highest reliability. However, the disadvantage of read-back check is that the entire programming process will take a lot longer. Because compared with the two steps of ‘erasing’ and ‘programming’, the ‘reading’ operation is the slowest.

Summary

Finally, let me share our experience: 1. Most customers will choose Checksum or CRC, because on the one hand, the verification efficiency is high, and on the other hand, there are functional tests and other links behind the production line to verify the integrity and correctness of the programming. 2. In most cases, customers reported that incorrect programming caused the circuit board to malfunction. After investigation, many reasons pointed to problems with the ‘source file’ itself (such as using the old version of the source file, or the source file of other products). Therefore, using MES systems to strengthen the control of source files can effectively avoid such misjudgments.