Hello everyone,

I recently prototyped my obstacle-avoidance bot's circuit on breadboard where it worked just fine after I fiddled for sometime with the 20 MHz crystal.

Apparently the crystal wasn't loaded enough (although I used 47 pF caps, I checked the caps and they weren't shorted) earlier as when I introduced some stray capacitance (when I took my hand near for example) the circuit started working fine.

This left me with a few questions:

1. Even after being powered properly (I used decoupling caps) the MCU seemed to put out abnormal voltages off its pins (I mean other than 0 V and 5 V).
The LED that I made the MCU light up on power-up, for example, seemed to glow very dimly and was flickering. Is this an indication of crystal problems or was it a one-off case?

2. It did occur to me that it might be one of those mysterious breadboard connection faults so I switched the crystal position elsewhere and a few moments later it worked first time.
Now that I soldered the entire circuit (I admit I am a green hand at soldering) I thought those problems would bother me no more. Instead the pins where there must be a clear 5 V and 0 V show weird voltages like 1.5 V or something.

This leads me to believe that the crystal may have been damaged earlier or during soldering (though I was very careful not to heat it much).

Could it be something else instead. What other factors could cause an MCU to behave in such a 'strange' manner?

Thanks (That was indeed quite long )

 

I think that 47pF is too much for a 20mhz crystal, I would use something around 18pF.
You also may have damaged the mcu with static discharge, you can test by using a potetntiometer to put voltage on the osc input pin and measuring the voltage on the osc output, it should act as an inverting amplifier to some extent.

edit: see for yourself the effective impedance at that frequency: http://www.pronine.ca/capimp.htm
anyway the manufacturer of the crystal should provide you with the recommended loading capacitance.

 

You also may have damaged the mcu with static discharge, you can test by using a potetntiometer to put voltage on the osc input pin and measuring the voltage on the osc output, it should act as an inverting amplifier to some extent.

I have been using the 47 pF loading caps for quite sometime now and they seemed to work fine. They were the only pF caps I had at that time although on the soldered board I used 33 pF caps which don't seem to be working either.

About the MCU. The last time I checked it was running fine with the circuit on the breadboard after I sorted out the (apparent) crystal issues. I used DIP sockets for soldering the IC on the breadboard so it isn't possible it might have been messed up there. What exactly could have caused the damage?

 

There are too many unknowns in order to pinpoint the cause of your problem.

1) What is the part number of your MCU?
2) Do you have a circuit diagram?
3) Can you post a photograph of your actual circuit?
4) What are you using for power supply?
5) Do you have 0.1μF and 10μF capacitors across the power supply?
6) Do you have a pullup resistor on the RESET pin?
7) Do you have a 10MΩ resistor across the crystal?
8) Do you have 15pF to 22pF capacitors on both pins of the crystal?

 

Is this the same project as the LCD display on the PIC16F877? In the future please say so, this time you were lucky your other thread got a hit today and I read it just before this one, or I would have zero idea what you were working on.

From your descriptions it seems you are using a solderless breadboard, and you only have a meter to probe, no scope. Both true? It sucks, but it's workable. I'm just using a DVM to get my current PIC project up (though I'm going for the scope later to verify the instruction rate).

The crystal portion will either work just fine, or do nothing at all. I've never seen them sorta/kinda work to make weird voltages.

When you see something like 1.5V on a digital pin it usually means it's changing and just the average value is 1.5. Same with the LED, if it is not constantly on you see that as a decrease in brightness.

While I don't see everything MrChips said as essential I cannot disagree with any of it. His point about the RESET pin (MCLR) is well taken, it has bit me a few times too.

It can sometimes really help to make one or more "sanity check" programs. These are programs that do very little but do something simple to check the circuit is alive and well. Something like a button is sensed and pin changed. I will even do things like invert a pin multiple times in a loop just to check the instruction rate (needs a scope for that).

I don't always keep these as separate programs, but they oft can be found as commented section at the end of my main(void) function.

 

There are too many unknowns in order to pinpoint the cause of your problem.

1) What is the part number of your MCU?
2) Do you have a circuit diagram?
3) Can you post a photograph of your actual circuit?
4) What are you using for power supply?
5) Do you have 0.1μF and 10μF capacitors across the power supply?
6) Do you have a pullup resistor on the RESET pin?
7) Do you have a 10MΩ resistor across the crystal?
8) Do you have 15pF to 22pF capacitors on both pins of the crystal?

A) I am sorry, I should have been more careful while writing. The processor is PIC16F877A.

B) & C) I just drew up a rough circuit diagram on paper because it wasn't actually very different from the several I've seen on the net, entirely my fault for not having foreseen such a situation. I do have a picture of the soldered circuit and I'll attach that in my next post.

D) I am current using a 12 V, 500 mA wall-wart as the prototyping power supply.

E) I do have a 0.1 uF connected across the output and GND of the 7805 of the MCU circuit. (Missed out on the input cap )

F) I soldered the MCLR directly to my +5V rail. No resistor in there! Another component I seem to have missed out (Should do better to make a circuit diagram next time). Although the supply is fairly constant and the MCLR pin is held at ~4.96 V, shouldn't it suffice for a crude application?

G) & H) No, though I don't have a resistor across the XTAL oscillator, I used the basic Colpitt's configuration with two 33 pF/47 pF caps from the XTAL to GND.

I seem to have missed out on a lot of things but apart from the resistor between the MCLR and the power rail, I used pretty much the same thing on the breadboard and it worked which lead me to believe that the circuit was fine (apart from the crystal issues which I pointed out).

Thanks for the pointers!

 

@ErnieM: Sorry for the confusion Nope, this isn't the same project. I am currently writing code for the other one and haven't gotten beyond the simulation while waiting for the hardware to ship.

I have had weird voltages on the PIC before but it was ~2.5 V or so and I realized that pin voltage was flipping too quickly. Initially, I reasoned the same way.

However, this couldn't possibly be the case here as I later discovered. While prototyping on the solderless breadboard as soon as I took my hand near the circuit the power on self-test LED used to brighten up and glow steadily. This was also the case when I touched the XTAL.

This lead me to believe that there might be XTAL issues in the first place. I admit I may have missed something somewhere in troubleshooting the circuit.

For now, I am thinking of redoing the circuit on a breadboard again with a RC oscillator circuit (the only XTAL I had is soldered on to the stripboard ).

 

Still some issues remain.

1) Not because a circuit or MCU is working in a given situation means that you have covered all the possible angles.

2) Do you have 0.1μF and 10μF capacitors across the power supply as close as possible to the MCU?

3) MCLR should not be connected directly to VDD.

4) As Ernie says, testing with a DVM is a poor way to trouble shoot a malfunctioning MCU.
Do you have access to an oscilloscope? What does 1.5V at a pin really indicate?

5) How do you know that your program correctly uses the external XTAL and not some other oscillator?

6) How do you know that it is an oscillator problem and not something else?

7) When making connections to a XTAL oscillator, layout and length of connections are extremely critical. That is why I ask for a photo.

 

Not sure if someone already mentioned this but have you turned off the LVP (low voltage programming) configuration bit in your program?

 

An update on the situation: I changed the crystal and wired up the PIC on my breadboard. It's supposed to light up an LED if it's alive and working which unfortunately doesn't look like the case now.

I'll try using the programmer with it to see if my fears are true anyway.

I'll let you know what happens. Hope I did not kill my MCU (it's my first one).

Fingers crossed!

 

The MCU seems to be behaving quite erratically.

The PICKit 2 recognized it okay on the first try though and I re-programmed it just to be sure. Weird voltages continued to appear on the port pins for sometime after which they magically switched to 5V and 0V

My happiness was not to last, however. When I powered the circuit down and started it again the circuit was back in the old weird mode and 1.5V continued to appear across both the terminals I specified as +5V and 0V explicitly.

Even on breadboard, the MCU appears to work fine when I press it a little hard or fiddle around with it a little bit and sometimes it just doesn't seem to be in a mood to work at all.

 

Try using it in debug mode to single step thru your code and see if the pin voltages seem better or at least stable.

(Gee, *NOW* do you get my point about getting a development board before starting off in micro controllers?)

 

Well, apparently the PIC was toast! I changed the MCU and everything looks and works fine now. It seems I did fry the chip the second time I inserted it into the socket wrongly. Apparently a PIC can only take so much.