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...
> 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
>
It happens to us all, Rolf. Nobody is laughing hard, and certainly not
at you.
On Sun, Feb 10, 2008 at 04:04:18PM -0500, Rolf wrote: {Quote hidden}
> 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...
I hear ya. I did the exact same thing a few years back, only I figured
it out only an hour. That said, the reason why it "only" took me an hour
was I'd just finished soldering up a very large project with 1,600 of
the damn things in it and well, flasher leds were on my mind. :)
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 removed}
One recent one for me was a PIC which was spontaneously resetting for no
apparent reason, even though everything I measured looked ok. It took
me forever to figure out that I discovered that I had missed disabling
LVP, and the floating RB4 pin (which wasn't yet connected to anything)
was sticking the PIC into programming mode as it toggled due to
capacitive and other effects.
> 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 ..........
>
Many years ago I built a Cockcroft-Walton voltage multiplier for testing leakage in underfloor heating cables. It worked to a point, but didn't give the predicted voltage. I added another stage, and another, but the voltage stayed the same. I'd picked up some zener diodes instead of rectifiers - exactly the same package, hadn't noticed the different part number! My boss called it the Cockcroft-Walton-Fletcher voltage regulator.
