Dear Expert
We use UCD3138RMH, repeatedly switch the machine about 200 times, read UCD3338 flash program all disappeared, we test our own backdoor program, the backdoor pin also did not move, so now I do not know what is wrong.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Dear Expert
We use UCD3138RMH, repeatedly switch the machine about 200 times, read UCD3338 flash program all disappeared, we test our own backdoor program, the backdoor pin also did not move, so now I do not know what is wrong.
I'm assuming that your backdoor program erases the whole program? Sometimes we see the checksum getting cleared in these cases. The cause has always been that there is excessive noise in the system, and the processor gets lost in the program and goes to the program section which clears the checksum. The same thing could certainly happen with erasing the program. Have you followed all the guidelines of the UCD3138 Practical Design Guideline Application Note? This covers not only grounding and filtering for noise reduction, but also requirements for power on rise time and monotonicity and for the reset signal. If these guidelines are not followed, things like this can happen. The note is here:
https://www.ti.com/lit/an/slua779b/slua779b.pdf
For extra protection, you can store the flash key in RAM. You need to add a RAM variable for the flash key, and a PMBus command to write the key to the variable before sending the erase command to the processor. Of course this will make your backdoor useless, so I suggest only using this on a tested production code that is verified to work and clear the flash from the PMBus command. The backdoor is really only intended for use in the development environment, especially if it just clears the checksum.