仲博cbin

Some customers have reported that the programmed chips are not functional during product testing after patch production.

After the chip is removed and the data is re-programmed, the product function returns to normal.

If you read the problematic chip data, you will find that the chip content is lost or rewritten.

Most customers may suspect that the programmer is poorly programmed when this problem occurs.

According to our actual analysis and verification of customer problems, this problem is not the cause of the programmer or the programming operation, which is basically caused by the following two reasons:

1. Most chips have an erase and rewrite function. When the product is powered on, the data may be accidentally erased or rewritten due to interference or software operation errors.

Therefore, we recommend that if the chip is a 25 series SPI FLASH, you can add "write protection" function during regular programming.

The operation in the SFLY programmer software is:

In the last step of the operation, add "write configuration", set the configuration options of the chip, and set the protection bit of the chip. As shown below:

*** The protection options of the chip need to be set according to the functional requirements of the product. Please consult the R&D engineer of the product for specific needs.

2. Another reason is the process or quality of the chip itself. When it is reflowed at high temperature, its data will be lost.

In this case, first check if the reflow temperature of the chip is too high, and if the soldering time is too long.

If the reflow parameters are normal, the problem is caused by the quality of the chip itself. It is recommended to consult the chip manufacturer or supplier.

How to tell if this problem is caused by the programmer:

1. First program a batch of chips for testing using conventional methods, such as programming 200 pieces, or 1000 pieces.
The operation content of the programming can be "programming + verification" (new blank chip), or "erase + check empty + programming + verification" (non-blank chip)

2. Verify the chip again after programming (ie 100% full inspection)
Set the operation content of the programmer to "check" (retain only the checksum, delete other operation items), install the same program file, and perform all verification operations on the chip.
*** Please do not use the method of reading and then comparing the checksum (this way of verification is not scientific).

3. Normal patch production

4. Product power-on test
If a bad product is caused by chip data loss, then it can be determined that the problem is in the step of patch production or subsequent testing, which has nothing to do with chip programming (because we have done 100% full inspection of the chip in step 2) .