Can't access PIC12F675 with ICD2

[Alex_rcpilot]

Hi guys.problems back,with the ICD2.But I think this time it's pretty much the problem about my understanding about the 12F675 rather than a programmer malfunction.

I was thinking about migrating a servo control system I built previously with ATtiny15L into a PIC12F675,found it impossible to access the PIC however(chip ID read 0x00),I noticed the 12F675 is somehow a little different according to some limited info I have in hand but not sure how exactly.Here's my hardware configuration:

It's a minimized circuit:Vdd = +5V,GND = ground,Vpp,CLK,DAT all connected to corresponding pins on the ICD2's cable.The chip has never been touched since shipment not long ago.

Do I have to do something to the hardware to help the ICD2 access ICSP mode?I searched this forum and found this:

Don't know about picall, but some programmers, like jdm, have problems with the 12f675 when running on internal oscillator. They turn VDD on before VPP and the pic starts running its program wich prevents it from going into programming mode, maybe the picall's problem is similar...

Is there a same problem with ICD2?What if I add a transistor to Vdd that switches on it right after Vpp is applied?My gratitude in advance!

 

[williB]

Alex i believe the F675 does not have on chip debugging..
i think that may be the problem

 

[Nigel Goodwin]

I can't help you with the IDC2, but I can clear up the confusion about internal oscillators!.

As you probably know?, to place a PIC in programming mode you need to place about 13V on the MCLR pin. But as well as this, the PIC must not be running at the time, or it's impossible to enter programming mode!.

The programming sequence consists of turning ON Vdd, then turning ON Vpp (that feeds the MCLR pin), if you have a PIC that contains an internal oscillator Vpp must follow Vdd BEFORE the oscillator can start! - and it's normal to have a delay between the two switching events. In order to make it work with internal oscillators this delay must be shorter than the oscillator startup time of the PIC - which is specified in the datasheet.

So there's no problem, as long as the delay time is short enough - I modified WinPicProg to make it a user setting - so you can shorten it as you wish. I originally hit the problem with the 16F628, but it applies to any PIC with an nternal oscillator.

 

[PicChristmas]

Have gone to Microchips site and looked under ICD 2 for the poster. This has a lot of information on how to connect the ICD 2.

How are you powering your PIC? You can only power the PIC with the ICD 2 if you have the wall wart connected to it. It will not power the circuit with the USB cable only.

Best guess is to check your power or the pin loading on the pins used by the IDC 2.

 

[Jay.slovak]

Hi guys.problems back,with the ICD2.But I think this time it's pretty much the problem about my understanding about the 12F675 rather than a programmer malfunction.

I was thinking about migrating a servo control system I built previously with ATtiny15L into a PIC12F675,found it impossible to access the PIC however(chip ID read 0x00),I noticed the 12F675 is somehow a little different according to some limited info I have in hand but not sure how exactly.Here's my hardware configuration:

It's a minimized circuit:Vdd = +5V,GND = ground,Vpp,CLK,DAT all connected to corresponding pins on the ICD2's cable.The chip has never been touched since shipment not long ago.

Do I have to do something to the hardware to help the ICD2 access ICSP mode?I searched this forum and found this:

Don't know about picall, but some programmers, like jdm, have problems with the 12f675 when running on internal oscillator. They turn VDD on before VPP and the pic starts running its program wich prevents it from going into programming mode, maybe the picall's problem is similar...

Is there a same problem with ICD2?What if I add a transistor to Vdd that switches on it right after Vpp is applied?My gratitude in advance!

What a coincidence! I have been playing with my ICD2 and 16F675 all day today.... I had some strange 0x00 problem too. Then, after I re-read the Datasheet, I realised Swapped VSS and VDD in my design (strange, it's different at 16F628). After that it works like charm... Also check if you are not Overloading PGD $ PGC pins of the ICD2 (eg LEDs...).

 

[williB]

jay is that a cable with a sip connector on thr end..?

 

[Jay.slovak]

jay is that a cable with a sip connector on thr end..?

The one that is stuck into breadboard is standart 5pin Female+Male connector (SIP, like 3pin FAN connector), the other end is soldered inside the box/case..

 

[Alex_rcpilot]

Alex i believe the F675 does not have on chip debugging..
i think that may be the problem

Well,ah...actually I'm a little confused with it.MUST a chip have on chip debugging function to be programmed serially?I found 12F675 in the MPLAB readme file for ICD2.So it's pretty certain that ICD2 supports this chip.And I only need to program it other than debugging.

I can't help you with the IDC2, but I can clear up the confusion about internal oscillators!.

As you probably know?, to place a PIC in programming mode you need to place about 13V on the MCLR pin. But as well as this, the PIC must not be running at the time, or it's impossible to enter programming mode!.

The programming sequence consists of turning ON Vdd, then turning ON Vpp (that feeds the MCLR pin), if you have a PIC that contains an internal oscillator Vpp must follow Vdd BEFORE the oscillator can start! - and it's normal to have a delay between the two switching events. In order to make it work with internal oscillators this delay must be shorter than the oscillator startup time of the PIC - which is specified in the datasheet.

So there's no problem, as long as the delay time is short enough - I modified WinPicProg to make it a user setting - so you can shorten it as you wish. I originally hit the problem with the 16F628, but it applies to any PIC with an nternal oscillator.

Yes Nigel,I understand about the sequence.But I don't think this DIYed ICD2 can set the Vdd-Vpp power up interval.Because the target board power supply mode selection is ignored by a hardware jumper.I can set the jumper to output Vdd or disable it.MPLAB never has access to the power management.This causes a problem:The Vpp can never be applied soon enough before the internal oscillator starts to function without my extra attempt in building a special circuitry.May I ask if the Vpp can be powered up prior to Vdd,with both CLK and DAT pulled down?And,as you know,12F675 is not the only chip with internal oscillators.Many other chips have them,e.g,16F877(A).Why does 675 have such configuration problem while 877 doesn't?I browsed throught the documents but couldn't find issues on default config values.If they're all "1"s,then external RC oscillators are designated for both 877 and 675.Signifying the 675 won't be powered up with internal oscillator running by default.I'm so confused!

This is from MPLAB help file.Pay attention to the sentence saying the chip must be clock.That makes me even more messed up!
PIC12F629/675, PIC16F630/676, PIC16F627A/628A/648A Limitations
Debugger Limitations
Programmer Limitations
Programming these devices while debugging may be slower as these devices do not have row erase capability.
Only ICD Versions

Only ICD devices (e.g., PIC12F629-ICD) can be used to debug with MPLAB ICD 2.
Only ICD devices can be programmed using the MPLAB ICD 2 Header. Use the Universal Programming Module (AC162049) to program non-ICD devices.
ICD devices must be clocked (internally on INTOSC or externally on OSC1) and have MCLR high to communicate with the MPLAB ICD 2.
A breakpoint cannot be set on a GPIO instruction. Since MPLAB ICD 2 I/O is through bits 6 and 7 of GPIO, setting a breakpoint on a GPIO instruction will cause communication problems.
Devices cannot be programmed or read while GP1/RA1 is high (Vih). Move circuitry that makes GP1/RA1 high to another I/O pin during development.

 

[Jay.slovak]

Alex i believe the F675 does not have on chip debugging..
i think that may be the problem

Well,ah...actually I'm a little confused with it.MUST a chip have on chip debugging function to be programmed serially?I found 12F675 in the MPLAB readme file for ICD2.So it's pretty certain that ICD2 supports this chip.And I only need to program it other than debugging.

I can't help you with the IDC2, but I can clear up the confusion about internal oscillators!.

As you probably know?, to place a PIC in programming mode you need to place about 13V on the MCLR pin. But as well as this, the PIC must not be running at the time, or it's impossible to enter programming mode!.

The programming sequence consists of turning ON Vdd, then turning ON Vpp (that feeds the MCLR pin), if you have a PIC that contains an internal oscillator Vpp must follow Vdd BEFORE the oscillator can start! - and it's normal to have a delay between the two switching events. In order to make it work with internal oscillators this delay must be shorter than the oscillator startup time of the PIC - which is specified in the datasheet.

So there's no problem, as long as the delay time is short enough - I modified WinPicProg to make it a user setting - so you can shorten it as you wish. I originally hit the problem with the 16F628, but it applies to any PIC with an nternal oscillator.

Yes Nigel,I understand about the sequence.But I don't think this DIYed ICD2 can set the Vdd-Vpp power up interval.Because the target board power supply mode selection is ignored by a hardware jumper.I can set the jumper to output Vdd or disable it.MPLAB never has access to the power management.This causes a problem:The Vpp can never be applied soon enough before the internal oscillator starts to function without my extra attempt in building a special circuitry.May I ask if the Vpp can be powered up prior to Vdd,with both CLK and DAT pulled down?And,as you know,12F675 is not the only chip with internal oscillators.Many other chips have them,e.g,16F877(A).Why does 675 have such configuration problem while 877 doesn't?I browsed throught the documents but couldn't find issues on default config values.If they're all "1"s,then external RC oscillators are designated for both 877 and 675.Signifying the 675 won't be powered up with internal oscillator running by default.I'm so confused!

This is from MPLAB help file.Pay attention to the sentence saying the chip must be clock.That makes me even more messed up!
PIC12F629/675, PIC16F630/676, PIC16F627A/628A/648A Limitations
Debugger Limitations
Programmer Limitations
Programming these devices while debugging may be slower as these devices do not have row erase capability.
Only ICD Versions

Only ICD devices (e.g., PIC12F629-ICD) can be used to debug with MPLAB ICD 2.
Only ICD devices can be programmed using the MPLAB ICD 2 Header. Use the Universal Programming Module (AC162049) to program non-ICD devices.
ICD devices must be clocked (internally on INTOSC or externally on OSC1) and have MCLR high to communicate with the MPLAB ICD 2.
A breakpoint cannot be set on a GPIO instruction. Since MPLAB ICD 2 I/O is through bits 6 and 7 of GPIO, setting a breakpoint on a GPIO instruction will cause communication problems.
Devices cannot be programmed or read while GP1/RA1 is high (Vih). Move circuitry that makes GP1/RA1 high to another I/O pin during development.

So, to sum everything up:
12F675 can be programmed by ICD2, but it can it can't be debugged!
However there are 12F625-ICD devices (14 pin) which are DEDICATED for ICD debugging... That's all.

 

[Nigel Goodwin]

Many other chips have them,e.g,16F877(A).Why does 675 have such configuration problem while 877 doesn't?I browsed throught the documents but couldn't find issues on default config values.If they're all "1"s,then external RC oscillators are designated for both 877 and 675.Signifying the 675 won't be powered up with internal oscillator running by default.I'm so confused!

The 16F877 doesn't have an internal oscillator, so the problem doesn't arise - there's only a fairly small number of PIC's with internal oscillators.

However, exactly the same problem arises when doing ICSP, and you have to select programming mode before the oscillator can start. I've recently modified WinPicProg to give an optional extra output pin - this pulses briefly at the start of programming, and can be used to RESET the PIC to allow you to select programming mode regardless of the oscillator configuration.

 

[Mike - K8LH]

Alex,

I just successfully programmed a 12F675 on my home-built Serial ICD2 but I included a circuit to effect ICD2 controlled Target VDD switching... I was hoping the ICD2 was smart enough to use "VDD first" and VPP first" methods for placing a target device into high voltage program/verify mode and so far I have not had any problems testing on a couple different devices with INTOSC enabled and MCLR disabled for Input...

I do get an ICD2 warning when I'm about to program this INTOSC/MCLR configuration into a target device but it programs the device fine, reads, verifies, etc., so perhaps this is simply not a valid configuration for In Circuit Debugging?

ICDWarn0033: MPLAB ICD 2 does not support programming this device if both the internal oscillator and internal MCLR are selected. You may continue programming, but you are encouraged to cancel, reconfigure your device, and try again.

Regards, Mike

 

[Mike - K8LH]

<off topic>

Jay (not Alex, grin),

I love the way you packaged your ICD2 Clone... Bravo Sir...

Regards, Mike

 

[williB]

Could somone put up a screen shot of what is on the screen when doing ICD2 ?

 

[Jay.slovak]

<off topic>

Jay (not Alex, grin),

I love the way you packaged your ICD2 Clone... Bravo Sir...

Regards, Mike

Thanks, I love simplicity

 

[Jay.slovak]

Could somone put up a screen shot of what is on the screen when doing ICD2 ?

Anything particular?

BTW: Look at my set:

 

[Mike - K8LH]

Jay,

Very nice Sir... Very clean lines... Bravo again...

Willi,

It's a remarkably unimpressive and only reasonably intuitive display in the form of a new tab in the Output window once you "bring up" the ICD2...

The ICD2 tab shows the commands you've initiated using the Programmer pull-down menu and displays warnings, process and command completion status messages...

After issuing a "Read" command from the Programmer pull-down menu, you have to use the View pull-down menu to look at the program or eeprom memory on screen, or you use the Configure pull-down menu to look at Configuration Bits or ID Memory...

If you load a new project with a different PIC and "bring-up" the ICD2 you'll watch it identify the target PIC and start "loading a new OS" into the ICD2 in the Output window...

I'll try to upload a sample image later, if Jay hasn't beaten me to it...

Regards, Mike

 

[Jay.slovak]

Jay,

Very nice Sir... Very clean lines... Bravo again...

Thanks again....

I'll try to upload a sample image later, if Jay hasn't beaten me to it...

Regards, Mike

Feel free to upload it, I am not in the mood of taking ScreenShots...

 

[Mike - K8LH]

Mike, K8LH wrote:
I'll try to upload a sample image later, if Jay hasn't beaten me to it...

Feel free to upload it, I am not in the mood of taking ScreenShots... Very Happy

Same here Jay... I'm right in the middle of something... I can sneak in a minute now and then to add a post to the Forum but I don't have time to bring up MPLAB and do a screen shot right now...

Willi, are you thinking about building an ICD2 clone?

Regards, Mike

 

[Jay.slovak]

Mike, K8LH wrote:
I'll try to upload a sample image later, if Jay hasn't beaten me to it...

Feel free to upload it, I am not in the mood of taking ScreenShots... Very Happy

Same here Jay... I'm right in the middle of something... I can sneak in a minute now and then to add a post to the Forum but I don't have time to bring up MPLAB and do a screen shot right now...
Regards, Mike

Ok, I will do it 8)

 

[Mike - K8LH]

Ok Willi,

Here's a screen shot...

Once you select a Programmer the Programmer pull-down menu opens up and gives you the commands you see here...

Let me know if you want to see more screen shots and I'll try to do some later...

G'day Mate... Regards, Mike