Post by thread:what are the five dumbest things to check?

Hi All: At the risk of offending the geniuses out there, I have a(nother) completely dumb question. I have a PIC application that works beautifully on a microchip demonstration board, and won't work on my own. Tring to isolate the problem, I went back to a simple LED-flashing program (calculating delays from the main crystal). On the demo board, it also works fine, but on my board it flashes irregularly, seeming to be "beating" with another much slower frequency. (The application I am working on has a watch crystal beating a 2-second period on Timer1, but this appears before the interrupt is enabled.) So far as I can tell (the 30th time through), the pins are all connected to the right power. MCLR is tied to 5V through a 4700ohm resistor. I am using a 16C74. The watchdog timer is disabled, and there are no interrupts enabled (yet). There is a 16x4 LCD attached to this all (works on the demo board, but doesn't initialize on mine), and I wondered if it was pulling the power down. I haven't been able to detect this, but my test equipment is pretty rudimentary. What would a pic do that was flirting with the brown-out protection? I am not expecting anyone to be able to diagnose my problems remotely, but I wonder if anyone who remembers their early blundering could jot down a list of the dumb things to check. I need more things to try, since I've run out of the things I know about. I feel like I am overlooking something right in front of my face, but I can't tell what it is. I am more or less at my wit's end (an alarmingly short distance), or I shouldn't have risked bothering you. Many thanks for any help or advice at all, -tom p.s. Many thanks as well for the help I've already been given, both to questions directly asked, and for help rendered to others in similar trouble. I'm learning about PICs on my own, and I don't have anybody here to ask these questions, and to provide reality checks. This makes this list a remarkably valuable resource, despite the goats, dutch humor, and other distractions. ---------------------------------------------------------------------- tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA

Tom, The first thing I find myself checking these days is ground - is the *bleep* board grounded properly (this after 2 weeks of debugging a serial line only to find that a 2 inch oiece of wire was the solution :( ) Then, did I remember to plug in the chip/emulator. Then, did I remember to turn on the PSU :) All the idiotic things - mainly because I've been taught by that 16c74a that I am a functional idiot :) After that, in this case, the oscillator bits in the config word - is it set to XT or whatever is appropriate ? Then an oscilloscope on the OSC2 pin to make sure the clock is working ! Hope it helps some ... -- Mark Dennehy, B.A., B.A.I. Email : spam_OUTMark.DennehyTakeThisOuTcs.tcd.ie Research Student, Computer Vision and Robotics Research Group, Computer Science Dept., Trinity College Dublin

In a message dated 97-12-18 10:29:04 EST, you write: << Hi All: At the risk of offending the geniuses out there, I have a(nother) completely dumb question. I have a PIC application that works beautifully on a microchip demonstration board, and won't work on my own. <Snip> >> Hello Tom! Sounds to me like you forgot to set the watchdog timer to off! Your program is trying to flash the LED but the watch dog timer is resetting the processor by way of its own time base. The result would be an eratticly flashing LED. Either turn off the watchdog when you program you part or add a CLRWDT instruction to your main loop. Hope this helps Dave Duley

Observation: Same PIC works on one board but not another. Axiom: The problem is caused by some difference between the boards. Thinks: just what are the differences? If you can't deduce the problem, test it by experiment. Change the circuit or components step by step until the iffy board should be exactly like the good one. At some point, the offending difference should disappear. What is your app, so we have an idea of how complex it is. Problems I have met: People giving me boards with wrong crystal values. Code not initialising variables to zero (this reduces the number of random start-up states) Floating inputs not properly pulled up (found when debugging an 80C188 design!) The crystals may be the same frequency, but are they the same cut/mode? (32.768 xtals are meant to run in Low Power oscillators - maybe one has be over driven and damaged and ticking erratically) Try it without the LCD. > makes this list a remarkably valuable resource, despite the goats, > dutch humor, and other distractions. > > ---------------------------------------------------------------------- > tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA

>On Thu, 18 Dec 1997 15:43:12 +0000, Keith Howell wrote: > Observation: Same PIC works on one board but not another. > Axiom: The problem is caused by some difference between the boards. > Thinks: just what are the differences? > If you can't deduce the problem, test it by experiment. > Change the circuit or components step by step until the iffy board > should be exactly like the good one. > At some point, the offending difference should disappear. Well, yes, but where to begin? The demo boards are about ten times as complex as what I need, and I'm not sure which parts are important and which are only important if I'm using an EEPROM chip or a keypad or a battery or whatever. > What is your app, so we have an idea of how complex it is. It is (embarrassingly) simple. It's similar to an LCD clock, with regular (2 sec) Timer1 ticks triggering updates to an LCD. There will be a couple of other inputs, but they're not installed yet, so for now, it's a clock. (On my board, the code apparently never makes it to the Timer1 interrupt enable, though.) > Problems I have met: People giving me boards with wrong crystal > values. Code not initialising variables to zero (this reduces the > number of random start-up states) Floating inputs not properly > pulled up (found when debugging an 80C188 design!) The crystals may > be the same frequency, but are they the same cut/mode? (32.768 > xtals are meant to run in Low Power oscillators - maybe one has be > over driven and damaged and ticking erratically) Try it without the > LCD. Thanks for the list. I'll be on it tonight. -tom ---------------------------------------------------------------------- tomss at ids.net - 401-861-2831 - 42 Forge Rd, Potowomut, RI 02818 USA

On Thu, 18 Dec 1997 13:24:47 -0500 Tom Sgouros <.....tomfoolKILLspam@spam@CIRCUS.GSO.URI.EDU> writes: >>On Thu, 18 Dec 1997 15:43:12 +0000, Keith Howell wrote: > >> Observation: Same PIC works on one board but not another. >> Axiom: The problem is caused by some difference between the boards. >> Thinks: just what are the differences? >Thanks for the list. I'll be on it tonight. No one seems to have mentioned it yet, but one of the simple mistakes to make with a larger PIC is not connecting all the power and ground pins. I think the 74 has 2 ground pins and maybe 2 Vdd pins. All must be wired in parallel to the circuit's power and ground.

The first thing I always taught my techs was check the supplies. Then, when they called from the field for help with a tough problem, I always asked if they checked the supplies. About half the time they went had to go do it and call back. So: check the supplies. When doing this, check that there's a good ground return path and that the PIC is bypassed with a suitable cap or caps (10uf tant + .01 is good). Then: get rid of everything but the board, the supplies and the led (w/ current limit, right?). Oh, yeah, and the crystal. Then get that working. If the same part can't work in the demo board and your board, there's only a few things that can be wrong, and which should be easy to find. BTW, if you're not using the same crystal as the demo board, change that, too. Then, when it works, change to the different crystal and get that working. Then add the peripherals. Good Luck. --Tom Rogers {Original Message removed}

Nobody's really responded with the five dumbest things yet. Here they are, with the dumbest first. I've done all of the following: 1. Check if the chip is in backwards (OR wait five minutes for the chip to start smoking). 2. Check to see if you have 5v (or 3v or whatever). 3. Check to see if you have 5v on the MCLR line. 4. Check to see if you have your watchdog time turned on AND a CLRWDT statement. 5. Check to see if the oscillator is oscillating. Nine times out of ten when I have a circuti that doesn't work, its one of these dumb things AGAIN. Best Regards, Lawrence Lile

Hi Tom (Tom Sgouros), in <9712181439.AA20275KILLspamcircus.gso.uri.edu > on Dec 18 you wrote: > Tring to isolate the problem, I went back to a simple LED-flashing > program (calculating delays from the main crystal). On the demo > board, it also works fine, but on my board it flashes irregularly, > seeming to be "beating" with another much slower frequency. Check the XTAL connections. Double check your LED test program. Watch the VCC rail on a scope. Try another PIC. Build a test circuit that contains _only_ the PIC, LED, XTAL+caps, and power supply connector. Go back to top :-)

At 09:39 AM 12/18/97 -0500, you wrote: >Hi All: > >At the risk of offending the geniuses out there, I have a(nother) >completely dumb question. I have a PIC application that works >beautifully on a microchip demonstration board, and won't work on my >own. If it were me I'd look very carefully at the oscillator. I've seen a lot of problems there over the years. The other thing I'd check is to make sure all "unused" pins are pulled up or down, I've seen floating pins cause interrupts and resets on more than a system or two. Wynn

I have observed that (a) PICs like a bypass capacitor directly across their power pins (b) The reset input is noise-sensitive and any tracks to reset should be as short as possible. Ensure also that the +5V rail is solid and noise-free, particularly in the area of the reset pullup. {Quote hidden}> ---------- > From: Wynn Rostek[SMTP:.....warKILLspam.....PALMNET.NET] > Reply To: pic microcontroller discussion list > Sent: Friday, December 19, 1997 6:30 PM > To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU > Subject: Re: what are the five dumbest things to check? > > At 09:39 AM 12/18/97 -0500, you wrote: > >Hi All: > > > >At the risk of offending the geniuses out there, I have a(nother) > >completely dumb question. I have a PIC application that works > >beautifully on a microchip demonstration board, and won't work on my > >own. > > If it were me I'd look very carefully at the oscillator. I've seen a > lot of > problems there over the years. The other thing I'd check is to make > sure > all "unused" pins are pulled up or down, I've seen floating pins cause > interrupts and resets on more than a system or two. > > Wynn >