Commandments for Using PICs

There are a few common problems that lead to unreliable PIC operation.  Based on my experiences and other people posting on the forums, here are several commandments that must be followed.

I've also added some comments about practices that I have found to work well for me.  These are not absolutes, but can smooth the development path.

If having problems with example and tutorial code, also check here for some guidelines.

Commandments

1.  All VSS and VDD pins on the chip must be connected.

Multiple pins are not put there for your convenience.  They must all be connected for the chip to work properly.  In the picture below, the VDD pins 11 and 32 must be connected to V+ and VSS pins 12 and 31 connected to ground.

PIC18F2420_PINS

 

2.  Bypass caps of 0.1 micro-farad are to be installed across VDD and VSS as close to the chip as possible.

Bypass caps must be used regardless of any other capacitors in the power supply circuit.  These may appear insignificant compared to large filter capacitors or capacitors used for the voltage regulator, but they must be used.

 

3. /MCLR must be pulled to VDD with a 10k resistor or explicitly disabled in code as Graham has explained.

A floating /MCLR pin may lead to intermittent operation, if the chip operates at all.

 

4.  Ensure that multiplexed port pins are correctly set up.

Many port pins can have multiple functions depending on how the PIC is configured.  When using these pins, ensure that the desired function is enabled.  Most notable are pins with analog functions, which often default to the analog state.  When planning to use these pins for digital functions, such as driving an LED or reading a switch, the digital function must be specified. 

 

5.  If using a development board, verify the purpose and connection of jumpers and accessories on the board, and understand the effect these may have on your circuit.

For example, if the development board has a pot connected to one of the analog inputs, your sensor input will be inaccurate or not seen at all.  Digital inputs may never change if the pot is rotated all the way to one end.

 

6.  The first programming step is a blinking LED program.

Trivial and silly, yes.  It verifies that the power supply is working, the chip is running, and that the programmer can actually program the chip.  If the LED flash rate is set to 1 second, it's also easy to verify that the clock is operating at the right frequency.

I had the mistaken idea that this went without saying but I've been proven wrong:

Once the oscillator configuration has been tested and the clock rate verified, do not change the oscillator configuration.  If the osciallor configuration is changed, the test must be repeated.

 

Suggestions

Some of these may go against the main-stream thought, but they work for me.

 

1.  Use a crystal oscillator.

It's hard to beat the simplicity and reliability of an external crystal, with 22 pico-farad capacitors on each leg to ground.  Internal oscillators may be used but this adds complexity to the code and there may be issues with start-up delays.

 

2.  Use ICSP and the PICkit 2.

Removing the chip each time it's programmed is a waste of time.  Boot loaders can work well, but ICSP is by far the easiest way to program a chip.  Using Microchip's PICkit 2 is the easiest and nearly the cheapest way to implement ICSP.  The logic analyzer and UART tool are additional benefits of the PICkit 2.

When using ICSP, it's best to keep the PRGC and PRGD pins dedicated to programming.  These pins may be used for other purposes if the design doesn't load the pins excessively.  See the Microchip documentation on ICSP for design ideas.

There are several designs for programmers that use a serial port or parallel port but these ports are rare on new computers, and available USB adapters don't always work.

 

3.  A good starting point for many programs is a UART output.

Even if a UART output is not to be part of the final project, setting up and testing a UART output can be a good idea.  Since the PICkit 2 makes it simple to monitor a UART output, adding the code at the start can aid troubleshooting later.  A message that says "subroutine 2, x = 5" is far easier to understand than an LED blinking on and off.

 

4.  Keep data sheets, schematics and programming documentation close at hand.

Having the necessary reference material handy makes programming easier.  

 

Troubleshooting

When things don't work as planned, a methodical approach is needed to find and correct the problem.  Beware the problem that suddenly resolves itself for no apparent reason - it may re-appear at any time.

1.  Check the power supply at the chip.

Some voltage regulators require a surprisingly large overhead voltage.  Make sure the chip has a solid supply voltage.  If a voltage regulator is used on the board, follow the data sheet recommendations for input and output capacitors.  These are separate and distinct from the bypass capacitors at the micro-controller.

2.  Check Connections.

If the blinking LED program does not work, check the connections.  If the power supply polarity is reversed, the chip is probably dead.  If the chip will not program, erase it, blank check it and try again.  Check the ISCP connections if it still fails.

If the LED does not flash, first check that the LED is connected to the correct port pin.  Also check the polarity of the LED.

3.  UART output:

No output:  Verify the RxD and TxD directions carefully.  The methods of identifying inputs and outputs varies and can be confusing.

Garbage Output:  The sender and receiver must be set to the same baud rate, parity and number of stop bits.  Any mismatch will result in garbage.  Note: if a software UART is used, the default state in Swordfish Basic is inverted.  This must be changed to communicate to the PICkit  UART tool.  Finally, verify the system clock speed is correct by checking the LED flash pattern as discussed above.  If the clock speed is wrong, the baudrate will be wrong.

4. Example and Tutorial Code

If example or tutorial code isn't working properly, check here for guidance.

 

Conclusion

There are a few common problems that cause many PIC circuits to fail.  A circuit may function even if these commandments aren't followed but its operation may be flaky or cease for no apparent reason.  Following these guidelines helps make a reliable circuit that will function consistently.


Posted: 2 years 1 month ago by Jon Chandler #11489
Jon Chandler's Avatar
Article updated to clarify a poor assumption on my part. The text in red has been added.
6. The first programming step is a blinking LED program.

Trivial and silly, yes. It verifies that the power supply is working, the chip is running, and that the programmer can actually program the chip. If the LED flash rate is set to 1 second, it's also easy to verify that the clock is operating at the right frequency.

I had the mistaken idea that this went without saying but I've been proven wrong:

Once the oscillator configuration has been tested and the clock rate verified, do not change the oscillator configuration. If the osciallor configuration is changed, the test must be repeated.
Posted: 2 years 1 month ago by majenko #11498
majenko's Avatar
3. /MCLR must be pulled to VDD with a 10k resistor or explicitly disabled in code as Graham has explained.
That should be a 10K resistor and a diode to block the high voltage from the Vpp of the ISCP from entering your power circuitry.
Posted: 2 years 1 month ago by hop #11499
hop's Avatar
That should be a 10K resistor and a diode to block the high voltage from the Vpp of the ISCP from entering your power circuitry.

I will 2nd that. I blew up a RTC that way once, at least I am assuming I did since it didn't work after I programmed my PIC. Also, and I cannot confirm this because I do not want to duplicate the issue, but I suspect not using that diode way back when was responsible for many of my programming failures.
Posted: 2 years 1 month ago by Jon Chandler #11516
Jon Chandler's Avatar
That should be a 10K resistor and a diode to block the high voltage from the Vpp of the ISCP from entering your power circuitry.

I will 2nd that. I blew up a RTC that way once, at least I am assuming I did since it didn't work after I programmed my PIC. Also, and I cannot confirm this because I do not want to duplicate the issue, but I suspect not using that diode way back when was responsible for many of my programming failures.

I've seen MicroChip documents which include a diode and which do not. Here is the diagram from the PICkit 2 manual.



This diagram shows a diode or a series resistor. I can't place my hands on materials from MicroChip that show it without at the moment but I've seen them.

Vpp can be as much as 12.5 volts depending on the chip. If there's no blocking diode or series resistor, this voltage is tied to Vdd via the 10kΩ pullup resistor. What will this do to Vdd? As long as Vdd is a "stiff" (low impedance) source, nothing much at all. The effect is about the same as a pullup resistor to ground.

I don't use a blocking diode and I've never had a problem. If the circuit was powered by a weak battery, Vdd might be pulled up but a battery that weak may lead to corrupt programming anyway. If the circuit is powered by the PICkit or a wall wart, the chances of a problem are pretty slim.
Posted: 1 year 1 week ago by Baldor #13543
Baldor's Avatar
Jon, what do you give to the Hack a Day guys? This article is featured in Hack a Day links today.( http://hackaday.com/2013/09/08/hackaday ... er-8-2013/ )
Posted: 1 year 1 week ago by Jon Chandler #13545
Jon Chandler's Avatar
I sent them an email suggesting this one and the vacuum pickup tool....a little shameless self-promotion


We've had some other articles from Digital-DIY posted there too, not just stuff I've posted. And recently, being mentioned on H-A-D hasn't crashed the server. Good job Graham!
Posted: 1 year 1 week ago by lespic #13546
lespic's Avatar
Re MCLR I have used diode in the past, but now i use a vdd < 10k | 100R >Vpp this combination works fine. I also usually include a LED driven from a port output to ground, that can be flashed as the program starts up, indicating the chip has power and the program is running.
Posted: 1 year 1 week ago by Baldor #13547
Baldor's Avatar
I think using a crystal is not necesary unless you need great acuracy (USB, for example). For many aplications the built in oscilator is good enough, uses less real state on the board, and frees two pins. And the configuration isn't more conplex.
Posted: 1 year 1 week ago by Jon Chandler #13548
Jon Chandler's Avatar
It shouldn't be that difficult to use an internal oscillator, but it's always proven to be a place where people have problems.

Also, in Swordfish Basic, if the internal oscillator setup isn't placed in a module, the FIRST module, it can take many minutes to execute code in all of the modules at the default oscillator speed before the code setting the internal oscillator is run.

The recommendations are based on areas where I've seen people get hung up and represent the best ways to avoid problems that can be hard to track down.
Posted: 1 year 1 week ago by Baldor #13549
Baldor's Avatar
Well, since I program in C, for me always have been the same, using a cristal or the internal oscilator. Just an include with all the configuration bits.

Also, the cristal is another point of failure if not properly placed.

Forum Activity

Member Access