PicLinks Page

Unerasable PIC-Chips - If you are using a UV-erasable PIC microcontroller, and inadvertently program it with the code-protection bits set, then you can never erase the chip again (we've spent a few $$$ learning this one).

Fried -MCLR Line (this is probably a new one on everybody) - If you tie an electrolytic capacitor directly to the reset pin (-MCLR) of a PIC UV-erasable microcontroller (as is common practice in microcontroller reset circuits in order to guarantee a slow risetime on the pin), you can damage the internal circuitry, such that, the chip will appear to erase and appear to program correctly, but some of the code will not run correctly. We've found that code space above the 2K boundary is most commonly affected, but there seems to be no repeatability as to what specific memory areas are affected. The giveaway that the internal circuitry has been damaged in these chips is twofold: (a) a large leakage current into the -MCLR pin is measured (up to 100s of uA, instead of < 1 uA), and (b) the erasure time of the chips increases dramatically, compared to chips without damage (we've spent a few $$$ learning this one, too).

The Microchip datasheet DOES mention using a 100-1000 ohm series resistor in the -MCLR line to limit current flowing from an external capacitor "in the event of MCLR pin breakdown due to ESD or EOS" - so Microchip appears to be aware of the general susceptibility of this pin, but their use of the term "in the event of" is some kind of doubletalk. In fact, tying a capacitor directly to the pin is the source of the electrical overstress.

Flukey PIC Execution (somehow related to previous item) - again, for UV-erasable chips, we have found that sometimes "perfectly good" chips will appear to erase and appear to program correctly, as indicated by the programmer, but some of the code will not run correctly. The usual first guess, of course, is there is a bug in the code, but this situation occurs with code that ran perfectly fine the time before. In this case, the chips are apparently not completely erased, even though the programmer indicates as much, and allows reprogramming and re-verifying of the chip. A longer erasure period usually solves the problem.

Another way to look at this is that, you can take the same working source code, program the chip twice in succession, and it may run differently in the two cases - if the chip was not erased for a long enough period prior to reprogramming.

The Microchip website microchip.com also has an "Errata" section with info about problems and errors encountered with their various chips. In actuality, there are problems with almost every chip.

PIC Fun'n'Games = "Hold RB3 Low" - circa 01 March 2002. [Note - this issue has been around for a while, but as noted below, it has only been a problem for us with the latest batches of PICs].

We have been programming Microchip PIC16F876 and several other 'F87x flash controllers for almost 2 years now using our vintage programmer with no problems. We use HVP [13v high voltage programming] exclusively. Suddenly, week of 24 February, we received a new batch of 'F876 chips and could no longer read/write/erase them.

Turns out you have to hold RB3 low during the HVP programming cycle to access the chips properly. We found this to be the case with chips from 2 out of 3 different batches purchased during the aforementioned week. This was not the case with the many, many chips programmed previously. There has been some mention of this problem on piclist/etc, but we had not encountered it with the 'F876, or with 'F873 or 'F874, chips until this point in time.

It is difficult to find reference to this issue on the Microchip site - it is mentioned in 2 errata sheets, although not for the chips we have been using. See Microchip errata page, and download the errata sheets for 16F870 and 16F872 chips. We also talked to customer service at two of our chip suppliers, and they were remarkably unaware of this problem.

The Fix. The solution to this problem is a programmer hardware modification. If using a programmer that performs HVP, wire the RB3 pin to ground using a low value resistor. Some people use a short, Microchip suggests a 10K resistor. We use 150 ohms. Note - there is apparently a similar issue with the 16F62x chips regarding pin RB4. See also: piclist.com and piclist.com

Another point to keep in mind. If you use LVP with the 'F87x flash parts, RB3 must be kept low on your target board (and therefore is not available for normal I/O), else the chip will leave operational mode and enter programming mode.

<| Scenix -(like PICs on turbo-boost)

Scenix Homepage: ubicom.com - datasheets and manuals - virtual peripherals

SX List: sxlist.com

SX dev tools: parallaxinc.com

Scenix Net Resources: svtehs.com - by Alexej Vladimirov, large list of compilers, development tools, and weblinks.

Eric's Scenix SX Page: brouhaha.com

<| Misc

Atmel: atmel.com - inc AVR micros.

AVR Forums: avr15

AVR programmers: links [1] [2] [3] [4], hardware [1] [2], software [1] [2]

AVR Resources: ipass.net, omegav.ntnu.no - also programmer, Forth

AVR Freaks: avrfreaks.net - also Phorum

AvrX Real Time Kernel: barello.net - and list of AVR tools.

Lucid Tech LP120: cs.net - general purpose programming system.

Embedded Webring: geocities.com

<| TOP