Junebug PIC18F1320 dead ?

[3v0]

Today in class 2 of my students were attempting to program TIMER1 and ended up with a PIC that would not ID. We swapped to another Junebug and the same thing happened to its target chip.

PICKit2 software shows No Device Found and No Device Detected. Swap in a good 18F1320 and all is well. When I move a bad chip between Junebugs the problem follows the chip.

We were using connector 8 hooked to a breadboard with LEDs on it. Given that the only signals on that connector other then the port bits is VDD and GND I do not see how that could damage the PIC to the point it would ID itself. There was not other power to the breadboard. At all times only the top 3 DIP switches were on.

What can no do to a 18F1320 to make it non responsive? I know it is a broad question.

 

[August Treubig]

Fuses

I have seen situations with other pics when you program the configuration fuses in some configurations, the pic won't respond to programming. Turning off MCLR and others can cause the pic not to communicate. My experience is that I had to put the pic in a simple minded programmer like a JDM and erase the pic. Once I did that, things got back to normal.

Aug

 

[eng1]

PICKit2 software shows No Device Found and No Device Detected.

I don't know why this can happen. I was debugging a routine (that failed to write to the internal EEPROM) with a PIC16 and I got the same error. I would have never thought that bad code could cause such a problem.

Erase the chip and you'll be able to use it again.

 

[blueroomelectronics]

I've nertz a 16F88 the by burning an unknow hex file onto it. It would report the wrong chip ID. I wound up just throwing it out.

 

[3v0]

Thanks guy erasing the chips with a JDM fixed them. Good thing I did not give it away

Now I have to figure out what they did to cause the problem.

 

[blueroomelectronics]

Hmm, maybe next time I'll pop it into the old PICStart+
I think the ID bits can be programmed, not officially of course.
I wonder if the PK2CMD.exe can force erase a PIC?

 

[Krumlink]

I think thats the first successful use of a JDM.

I too have accidentally fried a PIC: 16F877A. I guess running 25kV through the power pins makes it stop working

 

[eng1]

BTW you don't need another programmer I just used the PICKIT2 to erase the PIC! Then, it was detected properly again!

 

[August Treubig]

Fuses

I originally ran into the problem when I was putting one of Nigel's binaries on a 628A.

I think he turns of MCLR, since his boards don't really have a reset switch in the vanilla state. Mine do, resistor, diode, switch.

So I went back to either my JDM or my PicEl, one of the two. I may have to try messing one up again and see if the PicKit2 can erase it.

 

[3v0]

BTW you don't need another programmer I just used the PICKIT2 to erase the PIC! Then, it was detected properly again!

How did you get the PICkit2 to erase a chip that it could no see/detect?

 

[eng1]

How did you get the PICkit2 to erase a chip that it could no see/detect?

When I got that error, I just clicked 'Erase', then the correct device was shown by the PICkit2 software. Weird.
It would make more sense to erase the bad chip from MPLAB, where you can select the device (again with the PICkit2 programmer, though). That worked too.
Can you reproduce your problem and see if you too can do that?

 

[3v0]

I did not try it from MPLAB. Just the PICkit2 software.

If the PICkit2 does not know the device type could it erase it? I know it could not program it. I was thinking it would not do anything without a device type. Do not know if I tried erasing.

MPLAB where on could force the device makes more sense but I do not know if the program in the PICkit or ICD2 would allow it.

 

[kchriste]

A quote from the 18F1320s datasheet:

The Timer1 oscillator shares the T1OSI
and T1OSO pins with the PGD and PGC
pins used for programming and
debugging.
When using the Timer1 oscillator, In-Circuit
Serial Programming (ICSP) may not
function correctly (high voltage or low
voltage), or the In-Circuit Debugger (ICD)
may not communicate with the controller.
As a result of using either ICSP or ICD, the
Timer1 crystal may be damaged.
If ICSP or ICD operations are required, the
crystal should be disconnected from the
circuit (disconnect either lead), or installed
after programming. The oscillator loading
capacitors may remain in-circuit during
ICSP or ICD operation.

 

[blueroomelectronics]

A quote from the 18F1320s datasheet:

The Timer1 oscillator shares the T1OSI
and T1OSO pins with the PGD and PGC
pins used for programming and
debugging.
When using the Timer1 oscillator, In-Circuit
Serial Programming (ICSP) may not
function correctly (high voltage or low
voltage), or the In-Circuit Debugger (ICD)
may not communicate with the controller.
As a result of using either ICSP or ICD, the
Timer1 crystal may be damaged.
If ICSP or ICD operations are required, the
crystal should be disconnected from the
circuit (disconnect either lead), or installed
after programming. The oscillator loading
capacitors may remain in-circuit during
ICSP or ICD operation.

That only applies if you have a 32.768kHz crystal attached at the time. The wee crystal does not like great big square waves pounding at it and may break but the PIC is unaffected.

 

[justDIY]

I've nertz a 16F88 the by burning an unknow hex file onto it. It would report the wrong chip ID. I wound up just throwing it out.

I've got a 16f767 that does the same thing ... each time I program, my programmer reports it has failed, claiming programming the ID failed. I'm not sure why it's trying to program the ID, but other than that, the chip and program work 100%

 

[Pommie]

Looks like kchriste gets the prize. I just set bit 3 (T1OSCEN) of T1CON and the pickit no longer recognises the pic.

I haven't managed to erase it yet!

Mike.

 

[Pommie]

Just found a way to erase it.

In MPLAB I selected my Junebug as a programmer, connected a working circuit and did connect, swaped to broken circuit and did erase.

Mike.

 

[blueroomelectronics]

Good find, and yes the Junebugs tutor does not have the VPP before VDD mode. The Junebug only supports that mode on the ICD connector(s)

 

[kchriste]

That only applies if you have a 32.768kHz crystal attached at the time.

That's what I thought when I read it the first time. Then I read it again.

Looks like kchriste gets the prize.

WooHoo! What did I win?

 

[3v0]

Great. Now I can go into class knowing what went wrong. When I read the data sheet I understood (wrong) that T1OSCEN did not have any effect when TMR1CS was 0.

I have been spoon feeding them too much. Yesterday I asked them to setup TIMER1 and get it working without me pushing the effort. One of them asked my if we needed to set T1OSCEN and I said no. Yipes.

This was a big help.

Thanks khristie, Mike, and BIll for looking into this while I was napping