{"id":154504,"date":"2024-10-22T16:56:37","date_gmt":"2024-10-22T08:56:37","guid":{"rendered":"https:\/\/www.opteeq.com\/en\/?p=154504"},"modified":"2024-10-22T16:57:29","modified_gmt":"2024-10-22T08:57:29","slug":"expert-discussion%e4%b8%a8how-to-ensure-the-accuracy-and-integrity-of-the-programmed-data","status":"publish","type":"post","link":"https:\/\/www.opteeq.com\/en\/news\/expert-discussion%e4%b8%a8how-to-ensure-the-accuracy-and-integrity-of-the-programmed-data\/","title":{"rendered":"Expert Discussion\u4e28How to ensure the accuracy and integrity of the programmed data?"},"content":{"rendered":"\n

<\/i>\uff1aHow to ensure the accuracy and integrity of the programmed data?<\/h3>\n
\n

<\/p>\n\n\n\n

The most basic and important function of a programmer is to program data (source file) correctly and completely into the chip<\/mark>. 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.<\/p>\n\n\n\n

In order to discuss this issue, let us first clarify the following definitions:<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

Definition of source files, programming files and reading files<\/h2>\n\n\n\n

1.Source Files<\/strong><\/p>\n\n\n\n

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

2.Programming Files<\/strong><\/p>\n\n\n\n

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

\"\"<\/figure>\n\n\n\n

3.Reading Files<\/strong><\/p>\n\n\n\n

Reading file refers to the file generated after the chip is read by the programmer after the programming is completed.<\/p>\n\n\n\n

<\/p>\n\n\n\n

*The following figure helps you understand the definitions of the three files above:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The content of the reading file is inconsistent with the source file or the programming file?<\/h2>\n\n\n\n

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.<\/mark><\/p>\n\n\n\n

<\/p>\n\n\n\n

The inconsistency between the ‘source file’ and the ‘programming file’ may be caused by the following reasons:<\/h2>\n\n\n\n

<\/p>\n\n\n\n