Interpretation of ID code of PIC16 series microcontroller

I have seen many beginners confused about reading and writing ID codes of PIC16 series microcontrollers. To be honest, the information on this aspect is not very complete. Some textbooks may involve the introduction of the ID area, but they are often passed over in one generation. This is a place where beginners are prone to make mistakes. Today I have some free time, so I have sorted out some related issues and shared them with you. Maybe some of the explanations are not appropriate, and you are welcome to discuss more.

1.What is an ID zone?

The ID area is independent of EEPROM, FLASH, and RAM. Programmers can use this area to store software version numbers, writing dates, burning dates, product identification, and other information. However, this area is very small and the PIC16 series can only store 4 bytes.

2. How do I burn the ID code into the ID area?

This can be achieved by using the PICC's own macro command IDLOC(X). The specific operations are as follows:

.....................................//Other macro definitions in header file__IDLOC(76F4); //Note: There are two underscores in front. There can be up to 2 bytes in the bracketsvoid main(){...................................//Program body}

After compiling, use the burning tool to burn it into the microcontroller. Here is a reminder that there are at most 2 bytes of hexadecimal numbers in IDLOC (X), and the part exceeding will be invalid. For example, if you write 987FE3, E3 will be lost. In addition, I have to talk about how these two hexadecimal numbers are placed in the ID area. We already know that there can be 1 byte in IDLOC (X), and the ID area can hold 4 bytes. Taking X=76F4 as an example, they are placed like this: 07060F04. In other words, add 1 zero in front of each hexadecimal number. If you write a hexadecimal number that is not a 2-byte 2-byte hexadecimal number, such as a 1-byte 78. The compiler will add 0 in front, and it will become 0078. What is written in the ID area is 00000708

3.How to read the ID code?

It can be read out by burning tools and compilers. I used PICC and ICD2. After connecting the wires and powering on the microcontroller, in programming mode, execute the Read Target Device operation, and then enter the Id memory in the Configure menu.

You can see the ID code you set when programming just now in the option.

In fact, most PICs do not have a unique ID. Some people achieve this by burning the PIC readout bus, but the equipment needs to be homemade.

As long as it is a chip sold in large quantities on the market, decryption is not a problem. You can only try to use new or uncommon models.

Some people have done this using the EEPROM inside the MCU, but it is not that simple. For mass production, some skills are needed to better handle this problem.

1. Set up a self-test program and perform special operations (I have a homemade tool that can force the relevant IO of the MCU to be fixed at a certain logic level. The software determines the logic combination and must meet a specific combination to enter the special operation startup code. The UART receives the communication data of the tool, and the communication data is transmitted to the EEPROM to be erased and written. The number of times and position, etc.).

2. After entering the self-test, the MCU frantically erases a certain position set in the EEPROM (properly increase the VCC voltage to accelerate the failure), and stops operating after a maximum of 2 million times of erasure. Generally, the number of erasure times of the EEPROM of the MCU is less than 1 million times. A certain byte of the EEPROM is continuously erased and written between 0XAA and 0X55.

3. The time for erasing is relatively long, usually more than tens of minutes. I usually perform this self-test procedure during the product power-on aging stage (the product generally needs to be powered on and aged in the aging room for 4 to 6 hours, and the self-test procedure is compatible with this time to avoid new work-hour losses)

4. During the erasing process, the number of operations when the EEPROM byte fails is recorded in the RAM and stored in other bytes of the EEPROM.

5. During normal product sales, execute the APP user program and continue to erase the invalid byte. If it cannot be erased, it means the encryption is successful. Otherwise, there is another error correction program that I will not talk about. You can find a solution on your own.