We've all done something similar I would have thought.

I had one last week where the code would simulate fine on MPLAB but when 
burned to an 18F1320 all I could get out of most of the pins would be a 
logic high rather than the pulses I was expecting.

Only took me an hour to work out that I hadn't bridged the grounds on the 
breadboard to the lower half of the board with the PIC on it.

Thank goodness for scopes ..........
Dom
----- Original Message ----- 
From: "Rolf" <learr@rogers.com>
To: "Microcontroller discussion list - Public." <piclist@mit.edu>
Sent: Sunday, February 10, 2008 9:04 PM
Subject: [EE] One of those dumb mistakes....


> Here's one that will make you guffaw a little.
>
> I have just started programming a PIC, fresh project, etc. I set up new
> MPLab 8.01. I copy and past a bunch of C18 code from another project I
> did hoping to avoid issues with initialization. The previous project
> meticulously goes through every peripheral and
> enables/disables/configures it as required (I am using the same PIC as
> that project). I thought if I copied that code it would ensure that I
> got all the initialization right. I also copied some routines for
> reading/writing the EEPROM.
>
> Well, I took an hour and went through the code to cut out all the cruft
> I did not need, and was pretty certain that I had everything set up how
> I wanted it (timers, ADCon, Interrupt Priorities, etc.). I decided that
> I would add a blinking light to indicate the status of the program
> during setup.... just to get things going.
>
> Well, first the LED would not blink, and I realized the initialization
> routine was setting the TRIS to input. So, I set it to output, and the
> LED started blinking, but it was blinking faster than I wanted... so I
> slowed down the delay loop. Still blinking just as fast.
>
> Bugger, something was funny. I looked through the code, found no obvious
> problems. Figured the WDT or some other reset was happening. Built code
> to read the reset RCON status and interpret it. But, it was normal. Set
> ICD2 to debug, and read RCON, and every reset was either POR or MCLR
> Reset as expected from ICD2 debug.
>
> Finally, in frustration, I put a meter over the LED and discovered that
> even though the output pin was constantly high, the LED was still
> flashing.....
>
> Hmmm... I had pulled a 'flasher' LED from my junk box. Replaced it with
> a standard LED, and wrote a mail to Piclist so that you can all laugh at
> me.... ;-)
>
> 2 hours of debug, and now a flasher-LED that has been clearly marked
> with a Sharpie...
>
> Rolf
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.0/1268 - Release Date: 
> 09/02/2008 11:54
>
> 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist