Ruined U2 Programmer?

It has been a very good week - lots of progress and I'm feeling a little proud of myself... until last night.

I managed to let the smoke out of an L293 driver chip, but the fire was quickly subdued and I was sure that the damage was localized (the curtain is easily replaced and I'm sure the hair will grow back), This, now, seems not to be the case (the localized damage part - I am still certain about the hair).

I first realized I had a problem while programming an 16F88... The little stepper motor I'd been working with just wouldn't go. At first I thought I'd somehow mistyped, but much checking and I determined that a couple of ports wouldn't work. Clearly I'd done more damage than I thought. A new 16f88 and... no joy. Uh oh.

So, next I tried the [bottom of page] code on a 12F683. This works... only partially. The LED on GPIO.2 flashes as expected, but not GPIO.0 or GPIO.1 - in any configuration (that is, with or without any other port "plugged in" similarly). I went back to the 16F88 - with another chip, similar "blink LED" type program and, results are similarly inconsistent. Sometimes plugging in one port or another, one LED may blink, but always wrongly. That is, PORTA or B some LEDs blink as expected, others not at all.

I removed from ICSP and mounted chips directly in the programmer, in case some capacitance or supernatural thing was affecting my result; not that I can determine. Always the program cycle completes, the chip may be read, EEPROM values are stored properly and fuse bits seem to be set and saved, but... always there is some inconsistency in the operation of the ports.

At this point, with the number of chips that are failed and the number of configurations tried (I do not list all), I can think of nothing else it might be other than the U2 programmer. I must admit however, that it seems unlikely that every detail (including the power/ programming LED indicator) would appear to function, but leave inconsistent results in such a way. Or is it?

Oh, and yes... the power supply is solid 5V and filtered as it has been all the while everything worked so well.

First, I suspect it is wise to verify my test program (below). This will, I believe, blink GPIO 0, 1, and 2 at approximately 1 Hz, yes? Second, is anyone familiar enough with U2 (or know of documents) that I might use to troubleshoot the function of the programmer? Last, can anyone think of some possible issue I have not addressed?

Code:

---

OSCCON = %01110000  '8 MEG INTERNAL
DEFINE OSC 8                ' TELL EVERYBODY
TRISIO = 0                    ' OUTPUT ONLY
ANSEL = 0                      ' DIGITAL
   
MAIN:
  GPIO.0 = 1
  GPIO.1 = 1
  GPIO.2 = 1   
      Pause 500        ' Delay for .5 seconds
  GPIO.0 = 0
  GPIO.1 = 0
  GPIO.2 = 0
      Pause 500        ' Delay for .5 seconds

Goto MAIN         

End

---

Yes, I think there's a problem with the programmer.
But I'm not referring to the U2. :)

Code:

---

CMCON0 = 7    ; disable comparator

---

And don't change individual outputs so fast. You will begin to see the Hardware R-M-W issue.
Either set them all at once, or put a small delay between changing separate pins.

Code:

---

OSCCON = %01110000  '8 MEG INTERNAL
DEFINE OSC 8                ' TELL EVERYBODY
TRISIO = 0                    ' OUTPUT ONLY
ANSEL = 0                      ' DIGITAL
CMCON0 = 7

MAIN:
  GPIO = %00000111
  Pause 500        ' Delay for .5 seconds
  GPIO = %00000000
  Pause 500        ' Delay for .5 seconds
Goto MAIN

---

BTW. If you turn on "Verify After Programming", and it verifies ... the U2 is working properly and the chip has been programmed successfully.
To insure all sections of the PIC are being programmed, go to Options > More Options > Set Options to Defaults.

Humor, advice, salvation - I think we have made a Hallmark moment perhaps?

I am at work and cannot try this yet, but was eager to thank you. I tried so many configurations on both the '88 and '683 that I cannot be positive that this is the whole solution. Surely you are right that "verify" shall be proof beyond doubt; I feel the fool for not having considered this myself.

In the case that I have not another opportunity in advance, I wish you all a happy Thanksgiving. All the best to you and yours throughout the holiday season.

Also, the U2 programmer has some sort of short circuit protection built in, and I know that by experience :). There was one time I was programming ICSP in a circuit that had a short in the power lines. Nothing happened to the U2 programmer, but the USB port got broken. Luckily, I was using a USB hub and that was the only thing that got fried.

Robert

Well, to close this thread I will relate my findings.

With Darrel's help and assurance from Robert that the programming device should still work, I began exploring my issue.

Even with the corrected software and code verifying, I had problems as before. No amount of frustration seemed adequate to resolve the issue. From my research it seems that none of the chips would sink current, unless another pin was in use - except, when it would (I know, but really... this is how it appeared to be). My 'scope - an old one, but freshly calibrated - showed only a 3V drop between pin HIGH and pin LOW (verified by the faint glow of LEDs alternately connected). Yes, except when it was a 5V drop and all worked as it should. It was very frustrating to be so inconsistent.

As an alternative to chewing off my thumb, I tried another new chip - number five. All the four previous with the same issue, a mix of 3 16F88 and 1 12F683, oddly working and driving (or not) LEDs on different pins.

Johnny was right - number 5 is alive; every issue is magically corrected.

For my farm I cannot understand how... Chips that have worked perfectly and were put away carefully, packed in non-conductive foam and in a non-conductive box (from my favorite cigars) were fails of exactly the issue of those I had exposed to damage. I tell you frankly, had any of you explained the issue I could not believe the truth of it, and yet...

Now I do not know whether to investigate my neighbors for some unauthorized death ray pointed haphazardly or to search in the basement for fear my wife has nuclear waste stored without my knowledge. Or perhaps it was some intermittent USB or programmer issue (the electronic one, not the burned curtain, missing one eyebrow from fire one) that will haunt me again in the future. At this point, one answer seems as likely as the others.

Before you close the thread...

Did you try turning off Capture/Compare/PWM?

CCP1CON = 0?

To the point of not pulling down to 0 volts on the pins, turn off global pull-ups:

OPTION_REG.7 = 1 (1 is disabled).

Don't close a thread. You never know if more posts will be useful. Admins only close threads that get out of hand.

Robert