Can't access PIC12F675 with ICD2

[Nigel Goodwin]

...it will then switch MCLR directly from 0V to 13V, which selects programming mode more than fast enough for the oscillator not to start up.

My latest version of WinPicProg adds an extra output line for this exact reason!.

Hi, Nigel. Does the P16PRO40 programmer needs modification for this new feature to work properly?

Yes, the P16PRO40 isn't designed for ICSP - the WinPicProg ICSP changes were added for a specific series of ICSP PIC based boards. They consist of an interface board that connects to the PC, and target boards that plug directly into it. The interface board is powered by the 5V from the target board, and generates the 13V Vpp voltage using a switchmode PSU.

It makes for a small and easy to use system, and I've also added 'Run', 'Stop', and 'Reset' buttons to WinPicProg - so you can control the board (very basically!) from the software.

The boards 'should' be available in a while, hopefully later on this year?, and at low cost.

But the changes to WinPicProg are designed to be easily customised, you can select which pins it uses, and their polarity, so you can easily make your own.

 

[Alex_rcpilot]

Hi Nigel.I've seen your answers.Perhaps I'm still stuck somewhere.Well,the default config bits are all '1's,so the osc section is '111'.According to the datasheet:111=RC Oscillator.It seems the internal oscillator wouldn't function under such conditions.

The part about RC2 really reminded me that a power-on state is not the only way to enter programing mode.My ICD2 certainly has this pull down mechanism on RC2.And this eliminates the need to take special care of any power supply.Consequently however,my problem with 12F675 will seem more ridiculous.I'm lost.

BTW,here is the document I mentioned above,which has a diagram indicating Vpp needs to be powered up at the least 5us before Vdd is on.This doesn't make sense.Please help me understand it.

Regards,Alex

 

[Nigel Goodwin]

Hi Nigel.I've seen your answers.Perhaps I'm still stuck somewhere.Well,the default config bits are all '1's,so the osc section is '111'.According to the datasheet:111=RC Oscillator.It seems the internal oscillator wouldn't function under such conditions.

No, that selects the RC oscillator - as far as I'm aware none of the PIC's default to using the internal oscillator?.

The part about RC2 really reminded me that a power-on state is not the only way to enter programing mode.My ICD2 certainly has this pull down mechanism on RC2.And this eliminates the need to take special care of any power supply.Consequently however,my problem with 12F675 will seem more ridiculous.I'm lost.

If the PIC is set to use MCLR as an I/O pin, as it's likely to be with only 8 pins available!, you won't be able to reset the PIC by pulling MCLR low. So if you can't switch Vdd you won't be able to enter programming mode.

BTW,here is the document I mentioned above,which has a diagram indicating Vpp needs to be powered up at the least 5us before Vdd is on.This doesn't make sense.Please help me understand it.

Presumably this is to overcome the MCLR problem I mentioned above?, but there appears to be no need to do it this way - WinPicProg turns Vdd on first, delays a short time (set by Vpp Delay on the hardware screen), then takes Vpp high.

As I see it, using the ICD2, if you set MCLR as an I/O pin, and select internal oscillator, you then can't access programming mode any more?.

 

[Jay.slovak]

As I see it, using the ICD2, if you set MCLR as an I/O pin, and select internal oscillator, you then can't access programming mode any more?.

It should work if you power it from ICD2.

 

[Nigel Goodwin]

As I see it, using the ICD2, if you set MCLR as an I/O pin, and select internal oscillator, you then can't access programming mode any more?.

It should work if you power it from ICD2.

Not from the ICD2 clone from your signature, as it doesn't provide Vdd switching - I can't comment on the original MicroChip version as I don't have it's circuit?.

 

[Jay.slovak]

Here are Schemes of Original ICD2 and my Clone:

 

[Alex_rcpilot]

Jay,thank you for that script.I've kept a copy for further reference.

Alright,let's sum up everything:

It's clear that the default osc config bits are 111,designating external RC oscillator.This puzzles me about why the problem still arises that PIC12F675 will start running on its own preventing ICD2 access.Nigel has been really patient explaining everything for me but I just turned out to be thickheaded.

Having asked so much about what your circuits look like,I would like to put my scheme here in order that it will be easier to locate the cause of the problem.

As you can see from the diagram,target Vdd is set with a jumper,off control of MPLAB.And RA1,RA4 are left unused.I saw Mike's scheme implementing RA1,while in Jay's script,RA1 is not used.This makes me wonder whether RA1 functions in original ICD2.If it doesn't,did Mike modify the firmware to make use of it?BTW,Mike,could you tell me how RA1 in your circuit works?Does it activate RA4 when low and deactivate it when high?If that's the idea,please not that target chip is acting as a pull down resistor too.Even if RA1 is high,the drain current through the chip will still activate the transistor.Or,assume the chip has an extremely high impedance that you can take it as open circuit.You can successfully eliminate Vsd by holding the RA1 high,and nearly no current is supplied through the transistor.Vdd is still on,because you held the drain pin of the transistor high to do this.The target Vdd is already engaged.(Powered from RA1 through R15).I think we may put an combination of several NAND gates to generate such logic.('NOT' first,then 'NAND'output to the base of a PNP or grid of the MOSFET in your sch).Correct me if I'm wrong.

Concerning the access problem of 12F675 may be caused by the Vdd supply controlling circuitry.I added a PNP in my target board as below.The base is connected to RA4,regainning its control from MPLAB.I hoped that it would work.But it disappointed me again.

Is there anything I have neglected that makes the problem remain?People who have programmed 12F675 successfully,please bring me some clue.

Thanks.

 

[Jay.slovak]

Jay,thank you for that script.I've kept a copy for further reference.

Alright,let's sum up everything:

It's clear that the default osc config bits are 111,designating external RC oscillator.This puzzles me about why the problem still arises that PIC12F675 will start running on its own preventing ICD2 access.Nigel has been really patient explaining everything for me but I just turned out to be thickheaded.

Having asked so much about what your circuits look like,I would like to put my scheme here in order that it will be easier to locate the cause of the problem.

As you can see from the diagram,target Vdd is set with a jumper,off control of MPLAB.And RA1,RA4 are left unused.I saw Mike's scheme implementing RA1,while in Jay's script,RA1 is not used.This makes me wonder whether RA1 functions in original ICD2.If it doesn't,did Mike modify the firmware to make use of it?BTW,Mike,could you tell me how RA1 in your circuit works?Does it activate RA4 when low and deactivate it when high?If that's the idea,please not that target chip is acting as a pull down resistor too.Even if RA1 is high,the drain current through the chip will still activate the transistor.Or,assume the chip has an extremely high impedance that you can take it as open circuit.You can successfully eliminate Vsd by holding the RA1 high,and nearly no current is supplied through the transistor.Vdd is still on,because you held the drain pin of the transistor high to do this.The target Vdd is already engaged.(Powered from RA1 through R15).I think we may put an combination of several NAND gates to generate such logic.('NOT' first,then 'NAND'output to the base of a PNP or grid of the MOSFET in your sch).Correct me if I'm wrong.

Concerning the access problem of 12F675 may be caused by the Vdd supply controlling circuitry.I added a PNP in my target board as below.The base is connected to RA4,regainning its control from MPLAB.I hoped that it would work.But it disappointed me again.

Is there anything I have neglected that makes the problem remain?People who have programmed 12F675 successfully,please bring me some clue.

Thanks.

The problem with 12F675 is that when it's programmed with IntOSC & MCLR_OFF, not when it's blank! Also what do you mean that my design is not using RA1?

 

[Mike - K8LH]

Jay,

Thank you for posting the original ICD2 schematic... I have not come across it before... Very interesting...

Alex,

Your ICD2 clone looks way too professional and could get you kicked off the Forum (grin)... Try to include a notepad with conspicuous coffee cup rings and spill stains in the field of your next picture (grin)...

The RA0, RA1 and RA3 'ADC' pins and associated resistor dividers provide the Voltage Monitor functions... Since RA1 shows up as "Target VDD" in MPLAB I thought it should be measuring the voltage at the Target VDD pin on the ICSP connector but I suspect it really doesn't matter... I apologize for the confusion it caused...

Still not sure why you're experiencing the problem with the 12F675...

Nigel,

I've tried using the "VDD first" method (5-usec delay) on a few "VPP first" devices on my home brew 18F2320 based programmer and I couldn't get them into program/verify mode...

May I ask what "VPP first" devices you've been able to put into program/verify mode using the "VDD first" method and what kind of delay you're using between the application of VDD and VPP?

Regards, Mike

 

[Alex_rcpilot]

The problem with 12F675 is that when it's programmed with IntOSC & MCLR_OFF, not when it's blank! Also what do you mean that my design is not using RA1?

Well,I don't know what the current configuration is.I placed an application,Microchip delivered me a sample.That's all I know.It's a new chip,presumably all such new chips have INTOSC activated and MCLR off?Assume my 12F675 is just one of them,does it mean I may never be able to program it with ICD2?If I still can.How?

Or maybe people here who successfully programmed 12F675 had changed the INTOSC & MCLR_OFF state with another programmer before they tried ICD2?

The RA1.Please refer to Mike's diagram.The node connecting R15 and R16 is connected to label RA1.This circuitry indicates RA1 somehow affects Vdd output to the target board.While in your circuit,RA1 is connected to 2 resistors only.I don't know how RA1 works in Mike's circuit.That's why I asked Mike about it.

Regards,Alex

 

[Mike - K8LH]

The problem with 12F675 is that when it's programmed with IntOSC & MCLR_OFF, not when it's blank!

Jay,

This is wierd! The configuration you mention SHOULD be a problem... That is, configuring the device for INTOSC with MCLR disabled and configured as an input pin (MCLR internal)...

I've programmed this configuration into a 16F628A, a 12F683, and a 12F675 and afterwards I could still put each device into program/verify mode with the ICD2...

Mike

 

[Mike - K8LH]

Alex,

Is the ICD2 clone your only programmer at this time?

 

[Jay.slovak]

The problem with 12F675 is that when it's programmed with IntOSC & MCLR_OFF, not when it's blank! Also what do you mean that my design is not using RA1?

Well,I don't know what the current configuration is.I placed an application,Microchip delivered me a sample.That's all I know.It's a new chip,presumably all such new chips have INTOSC activated and MCLR off?Assume my 12F675 is just one of them,does it mean I may never be able to program it with ICD2?If I still can.How?

Or maybe people here who successfully programmed 12F675 had changed the INTOSC & MCLR_OFF state with another programmer before they tried ICD2?

The RA1.Please refer to Mike's diagram.The node connecting R15 and R16 is connected to label RA1.This circuitry indicates RA1 somehow affects Vdd output to the target board.While in your circuit,RA1 is connected to 2 resistors only.I don't know how RA1 works in Mike's circuit.That's why I asked Mike about it.

Regards,Alex

Programming Blank chips (aka brand new samples) mustn't be a problem! As Nigel supposed, their initial config is RC_osc + MCLR_ON

 

[Jay.slovak]

The problem with 12F675 is that when it's programmed with IntOSC & MCLR_OFF, not when it's blank!

Jay,

This is wierd! The configuration you mention SHOULD be a problem... That is, configuring the device for INTOSC with MCLR disabled and configured as an input pin (MCLR internal)...

I've programmed this configuration into a 16F628A, a 12F683, and a 12F675 and afterwards I could still put each device into program/verify mode with the ICD2...

Mike

That's exactly what I said!

 

[Nigel Goodwin]

May I ask what "VPP first" devices you've been able to put into program/verify mode using the "VDD first" method and what kind of delay you're using between the application of VDD and VPP?

I don't even know which ones might 'require' it?, all supported chips are programmed Vdd then Vpp. My version of WinPicProg here at work is set to 5uS Vpp Delay - but I don't know if I've ever programmed any such devices here or not?.

I'll check when I get home what it's set to there!.

 

[Alex_rcpilot]

Alex,

Your ICD2 clone looks way too professional and could get you kicked off the Forum (grin)... Try to include a notepad with conspicuous coffee cup rings and spill stains in the field of your next picture (grin)...

Ha,actually the only creative thin in my ICD clone is the picture pasted on the cover Like I said,these 2 PCBs are from a friend of my friend's.He drew the sch as well as designed the PCB.I only soldered the components and dug rectangular holes in the boxes I bought.Putting on a digital photograph designed with Photoshop eventually.I believe you can build a much better one if you want to.

Alex,

Is the ICD2 clone your only programmer at this time?

For PIC12F675 compatibility,unfortunately,yes :cry: .
I do have a domestic TOP151 and ISPro.But they are either for MCS-51 and AVRs.I've been working on 89S52 and ATmega16s previously.

Programming Blank chips (aka brand new samples) mustn't be a problem! As Nigel supposed, their initial config is RC_osc + MCLR_ON

Now I have 2 brand new PIC12F675 without INTOSC_on or MCLR_off,and I still can't detect them with ICD2 :shock: There must be something wrong I haven't noticed.I have to appologize for wasting everybody so much time on the INTOSC.Because it has actually never taken effect.

Has anyone found conspicuous problem in the sch of my ICD2 clone?Thank you.

BTW,Mike.I'd like to talk to you with some sort of instant messenger like MSN,because I'm interested in your device.It's kinda slow in a forum.Would you mind?My MSN is Alex_rcpilot@hotmail.com. (Note there is a lower dash in my ID like '_' following 'Alex')

Regards,Alex