Broken PIC12F675?

[fcoelho]

Hi, I've recently built the **broken link removed**, the alternate version, using a PNP transistor. It's working fine, but I've got problems while programming a 12F675 and a 16F628a. I'm using WxPic as the software programmer.

Yesterday, I was able to program a 12F675 with the following code, using HiTech C:

#include <htc.h>

__CONFIG(MCLREN & UNPROTECT & BORDIS & WDTDIS & PWRTEN & INTIO);

void main()
{
	TRISIO = 0;
	while (1)
	{
		GPIO0 = 1;
		_delay(100000);
		GPIO0 = 0;
		_delay(100000);
	}
}

I have two of these PICs, so today I've tried to program the other one, and it "worked". The programming was fine, but when I put it on the breadboard I've got no results. Vdd was 5.5V, but I measured on GPIO0 a constant ~4V. Then I tried the previous one, same result, programming was fine but not the output I wanted. May I have burned these PICs somehow? I tried also yesterday to program them on another computer, but there the software didn't recognized the programmer nor the PIC (I've tried it there with PicPgm, WinPic and IcProg). I tried to do it anyway, but it didn't work. Could it be the cause for the failing PICs? I've checked that the OSCCAL value is OK, but still it won't work.

Now, when I try with a 16F628a, it works fine and I have an awesome LED flashing in front of me. That at least proves that the programmer is working.

One thing that I find strange is that I cannot program any of them in Vpp-first mode. I read somewhere that for the 12F675 it had to be this way, but for the 628a too? The first time I programmed the 628a I used Vpp first and it worked, but when I tried to reprogram, it failed while verifying. I have the slight impression that I've read somewhere that when disabling MCLR, programming settings would have to change, but I'm not sure which one it could be. Anyway, it works if I set it to Vdd first.

I did disable MCLR, but I didn't find reasonable info relating those two, so I just switched to Vdd first and it was reprogrammed ok.

 

[AllVol]

I downloaded your program just now. Had to change the config statement to:

__CONFIG(INTIO & MCLRDIS & UNPROTECT & WDTDIS );

and its working just fine.


EDIT: Like the Eveready bunny, its still beating right along.

 

[fcoelho]

Mine doesn't really catch up to that. It seems like a bit of trial and error. Sometimes it just works, sometimes it just fails. I believe it has something to do with **broken link removed**, but I can't be sure of how to do it right yet.

Your change really worked, the circuit worked as expected. Now I've got to find a way to properly program them with "ease". It really is a matter of changing options in a certain sequence every time I try to program it. Do you know if USB programmers suffer from this issue also? What programmer do you use?

 

[kchriste]

When you program your PIC12F675 with MCLREN you must use a pullup resistor on the MCLR pin.
ie: A 10KΩ resistor from pin4 to Vdd when operating on the breadboard is required.

 

[AllVol]

Do you know if USB programmers suffer from this issue also? What programmer do you use?

To be truthful, I have zero knowledge about any programmers except my handy-dandy, ever-faithful, loving, trusting PICkit2 and LPC demo board. LOL. All I know is that, if I don't goof up, everything goes as planned. If something doesn't work, it always points to my error.

By the way, your program has been humming away continuously on my desk for the past 20+ hours.

Hang in there. All will be revealed.

 

[mvs sarma]

Hi, I've recently built the **broken link removed**, the alternate version, using a PNP transistor. It's working fine, but I've got problems while programming a 12F675 and a 16F628a. I'm using WxPic as the software programmer.

Yesterday, I was able to program a 12F675 with the following code, using HiTech C:

#include <htc.h>

__CONFIG(MCLREN & UNPROTECT & BORDIS & WDTDIS & PWRTEN & INTIO);

void main()
{
    TRISIO = 0;
    while (1)
    {
        GPIO0 = 1;
        _delay(100000);
        GPIO0 = 0;
        _delay(100000);
    }
}

I have two of these PICs, so today I've tried to program the other one, and it "worked". The programming was fine, but when I put it on the breadboard I've got no results. Vdd was 5.5V, but I measured on GPIO0 a constant ~4V. Then I tried the previous one, same result, programming was fine but not the output I wanted. May I have burned these PICs somehow? I tried also yesterday to program them on another computer, but there the software didn't recognized the programmer nor the PIC (I've tried it there with PicPgm, WinPic and IcProg). I tried to do it anyway, but it didn't work. Could it be the cause for the failing PICs? I've checked that the OSCCAL value is OK, but still it won't work.

Now, when I try with a 16F628a, it works fine and I have an awesome LED flashing in front of me. That at least proves that the programmer is working.

One thing that I find strange is that I cannot program any of them in Vpp-first mode. I read somewhere that for the 12F675 it had to be this way, but for the 628a too? The first time I programmed the 628a I used Vpp first and it worked, but when I tried to reprogram, it failed while verifying. I have the slight impression that I've read somewhere that when disabling MCLR, programming settings would have to change, but I'm not sure which one it could be. Anyway, it works if I set it to Vdd first.

I did disable MCLR, but I didn't find reasonable info relating those two, so I just switched to Vdd first and it was reprogrammed ok.

You are expected to compile and load the resultant .hex file into the PIC concerned, and hope that you did the same.

 

[fcoelho]

When you program your PIC12F675 with MCLREN you must use a pullup resistor on the MCLR pin.

Heh. Makes sense, otherwise it may be resetting all the time. Silly me.

To be truthful, I have zero knowledge about any programmers except my handy-dandy, ever-faithful, loving, trusting PICkit2 and LPC demo board. LOL. All I know is that, if I don't goof up, everything goes as planned. If something doesn't work, it always points to my error.

By the way, your program has been humming away continuously on my desk for the past 20+ hours.

I didn't think a flashing LED could be THAT awesome I was able to program them both to flash LEDs but I got bored after some time and just turned it off. Anyway, it seems most of the issue was with the MCRLEN switch, which I'll test with the pull-up resistor whenever I get back to the programmer. I still have issues to actually program it, as the verifying fails sometimes by a few words. When it verifies ok, though, everything is fine and I get the correct outputs.

 

[AllVol]

I didn't think a flashing LED could be THAT awesome

You should see my place... flashing LEDs everywhere from your program up to and through 64 LED arrays. Blink a LED and control the world, someone said.

Later

 

[Nigel Goodwin]

Blink a LED and control the world, someone said.

I thought it was "save the cheer leader and save the world"?

 

[Wilksey]

In my short experience with PIC's 99% of the issues that I have helped people out with is not pulling MCLR up.

Even if I disable MCLR (MCLRDIS) I still always tie it up, just to be sure.

It's an easy mistake to make, I kept doing it even though I had build a fair few boards, but now I have a small checklist that I use everytime I build a board, that way I never forget to do it.

Likewise on the 12F series of PIC's I have a programming checklist of what I need to turn on and off if I need to use a particular feature, because the 12F series are multiplexed I/O (the 12F510 is anyway).

I would recommend anybody doing occasional PIC projects to keep a list of do's and dont's for this reason.