Searching \ for '[EE] One of those dumb mistakes....' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=one+those+dumb+mistakes
Search entire site for: 'One of those dumb mistakes....'.

Exact match. Not showing close matches.
PICList Thread
'[EE] One of those dumb mistakes....'
2008\02\10@160440 by Rolf

face picon face
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

2008\02\10@170440 by Brendan Gillatt

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rolf wrote:
> 2 hours of debug, and now a flasher-LED that has been clearly marked
> with a Sharpie...

Ah, I feel for you! I sort of had the same problem with you - using a 5v
LED with a 3.3v circuit.


- --
Brendan Gillatt | GPG Key: 0xBF6A0D94
brendan {a} brendangillatt (dot) co (dot) uk
http://www.brendangillatt.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFHr3Truv4tpb9qDZQRAgT2AKDHHtLUov4MqJhxWCIl/leFsXAYCgCgvLbW
L/zxF3CTJC656hpApPc9TE8=
=2Mmg
-----END PGP SIGNATURE-----

2008\02\10@181028 by Bob Axtell

face picon face
Rolf wrote:
{Quote hidden}

It happens to us all, Rolf. Nobody is laughing hard, and certainly not
at you.

--Bob

2008\02\10@191517 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Feb 10, 2008 at 04:04:18PM -0500, Rolf wrote:
{Quote hidden}

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. :)

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHr4Tc3bMhDbI9xWQRAkY9AJ9XD8Zk/L073irVQYljabIVVe7TJgCfasU8
ZLe4OTFfm19iUYfQ1dGOve4=
=Pkv/
-----END PGP SIGNATURE-----

2008\02\10@200007 by Jinx
face picon face
> 2 hours of debug, and now a flasher-LED that has been clearly
> marked with a Sharpie...

Try having the scope probe on the wrong pin all day ..... Of course
it wasn't my fault. I can count can't I ? Well, on a good day maybe

Your and my cases are exactly why you should assume nothing.
Have a list, start at the beginning, tick everything that's proved
true along the way

Although even that doesn't work all the time unfortunately

2008\02\11@044525 by Picbits Sales

flavicon
face
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}

2008\02\11@053549 by Forrest Christian

flavicon
face
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.

-forrest

Picbits Sales wrote:
{Quote hidden}

2008\02\12@014712 by J FLETCHER

flavicon
face
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.
 
 John Fletcher

2008\02\12@093212 by Cedric Chang

flavicon
face
Reading about these boo-boos will help me down the road.
I am sure.
Cedric

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...