Precautions for using PIC low-end microcontrollers

1. When plugging and unplugging the power frequently, the PIC microcontroller is prone to crash. Use a 10K resistor and connect the 5V output of the LM7805 to the ground.

2. The capacitance of the reset terminal of the microcontroller cannot be too large.

-------------------------------------------------- --------------------------------------------------

    The most troublesome problem when using PIC microcontroller to design industrial control circuits is that PIC microcontroller often has hardware deadlock after being disturbed. Most people blame the "CMOS thyristor effect" for the deadlock phenomenon. It is generally believed that "hardware reset after deadlock is invalid, only power off". But for a mature product, do you need to turn off the power? It's like a refrigerator. When the compressor starts, it will cause interference. The CPU is disturbed and thus "hardware deadlocks". If you find it, you can unplug the power plug immediately and plug it back in after a few seconds. Is this action acceptable? If you don't find it when it's dead, and it's dead for dozens of days, what do you think will happen? It should be that the voltage regulator IC that supplies power to the CPU is burned out.

    Why does the PIC microcontroller have hardware deadlock? The PIC microcontroller often has hardware deadlock after being disturbed. Then what is the use of the PIC "watchdog"? Has anyone explored the reason in depth? There are many questions on various PIC microcontroller forums, and each has its own point of view. The specific reason is nothing more than the "CMOS thyristor effect" that causes the deadlock phenomenon. In my opinion, it should have nothing to do with the "CMOS thyristor effect", but many experts believe that it is caused by the "CMOS thyristor effect", so I have not been able to bring it up all along. Maybe my point of view is wrong, and it has misled everyone. But so far, there is no detailed explanation of the cause and the corresponding method for the deadlock phenomenon of the PIC microcontroller. This issue is still being raised in other PIC microcontroller forums. I will provide your reference with my experience in finding the PIC "deadlock phenomenon".

    Many years ago, PIC16C5x was produced for just one or two years (PICxxxx was originally only 165x, which was of NMOS structure and was widely used in general-GI channel selectors and cable TV unlockers. Later, it was changed to CMOS structure and renamed 16C5x). At that time, there were only four models: 16C54, 55, 56, and 57. The only emulator was the 16C5x DOS version emulator (first generation) manufactured by a top company. It was also the first OEM emulator factory of Microchip. 16C5x was the most power-saving OTP and QTP microcontroller at that time, and its price was cheaper than other microcontrollers, but it was easily interfered and crashed, so many large manufacturers did not dare to use it. One day, a friend asked me to design a car alarm for their company. At that time, all the car alarms on the market were designed with CD40xx logic circuits. Each time control required a set of RC circuits. There were more than a dozen ICs on the circuit board (plus the remote control decoding IC), at least 7 to 8 VRs, which were very complicated to adjust. At that time, I used a 16C55 + a ULN2003 + a decoding IC (the technology was not mature at that time, and the PIC program decoding was not used. The decoding IC was omitted later), a total of three ICs to solve the problem. Some of the circuits were transplanted from the circuits in the book (the reset circuit was also transplanted from a book on PIC application). After the sample came out, the other party had many questions. How can the circuit be so simple? There are 4 or 5 "timers" timing at the same time, and so many I/O detection tasks need to be done. Can the time control be accurate? How is the performance? Stability? ...... In general, the circuit designed by the CPU is definitely much better than the logic circuit in terms of function. As for the accuracy of the time control, I guarantee that all the time control errors are within 1%. As for stability, the samples at that time often crashed and the CPU overheated, which is what everyone calls the PIC hardware deadlock.

    For this problem (the problem that everyone fears the most), I searched all the information but found nothing. I didn't see any similar information in the PIC book, so I had to fight alone to find the reason. I spent several days simulating various situations, doing various experiments, creating various interferences, and using an oscilloscope to measure the abnormal waveforms at various points.

//////////////////////////////////////

    One of the simple experiments (connecting a pull-up resistor to V+, a 0.1uf resistor to ground, and a push button switch to ground on the MCLR pin) gave me the answer I needed. During the experiment, I pressed the push button switch many times. It should have just reset the device, but it was easy to get into the so-called "hardware deadlock". Continuous testing would repeat the same thing with a very high probability. Finally, I got the answer. There was a problem with the MCLR hardware design of the PIC chip. It was not related to other I/O pins. It was not that the I/O pins were disturbed, but when the MCLR was reset or disturbed, the MCLR pin would generate an oscillation signal. When a capacitor was connected to the outside of the MCLR pin, it would always oscillate. Some hardware reasons inside the PIC chip caused a large current to be generated between VDD and VSS, so VDD and VSS were like a short circuit, and the CPU became hot. When the capacitor was removed, The CPU started working again and the current consumption returned to normal, so I thought that the PIC was not hardware deadlocked and it did not have the thyristor effect of CMOS. Maybe people have not found the cause yet, and they suspect it is the thyristor effect of CMOS inside the PIC. I also reported the solution to this problem to Microchip at the time, and I don't know whether Microchip made any changes inside the chip afterwards.

-------------------------------------------------- --------------------------------------------------