p16pro trouble

[natbit]

Hi guys,

I've been trying out a simple 7-segment decoder on the 16F628 to get up and running with this chip - been using the 16F84a.

When I program the chip in PICALLW it briefly tells me that that it is blowing fuses or blown a fuse, it happen so fast I can't realy tell what the fuse number is (it did it with the '84a too damit!) I'm sorta shure I shouldn't choose the low power programing option - I'ts just the stock std. p16pro40.

I've looked at the .inc file (MPLAB) and imagined they were set right ? , is it PICALLW and are the fuses reset-able?

I don't like the thought of blowing these all the time, how can I lick this one?

natbit

 

[natbit]

The fuse on the '84a is 3FFF and '628 , 3FEA I think :cry:

 

[Nigel Goodwin]

Hi guys,

I've been trying out a simple 7-segment decoder on the 16F628 to get up and running with this chip - been using the 16F84a.

When I program the chip in PICALLW it briefly tells me that that it is blowing fuses or blown a fuse, it happen so fast I can't realy tell what the fuse number is (it did it with the '84a too damit!) I'm sorta shure I shouldn't choose the low power programing option - I'ts just the stock std. p16pro40.

I've looked at the .inc file (MPLAB) and imagined they were set right ? , is it PICALLW and are the fuses reset-able?

I don't like the thought of blowing these all the time, how can I lick this one?

:cry:

natbit

It doesn't 'blow' anything, it simply sets a bit in a byte of EEPROM - the term 'blow' comes from really old PROM's where it actually blew a fusible link. It's an old term which is still used today.

Don't worry about it!. If you don't like it, use my programmer software instead, it doesn't use such out of date frightening terms :twisted:

 

[natbit]

Hi Nigel,

What is it that's causing PICALLW to do it and what is it that your software does that it doesn't, is it shareware and have u a link?

I'm sorta keen to sort it out soon if u know what i mean...

Natbit

 

[natbit]

Nigel,

I took the plunge and am left stranded, I keep getting the ubiquitous

"Program verify failed at program address 0x000, programming aborted!"

I followed the FAQ and am pulling 12.8 V across MCLR, this should be enough for that particular problem, no?

:shock:

 

[Nigel Goodwin]

Hi Nigel,

What is it that's causing PICALLW to do it and what is it that your software does that it doesn't, is it shareware and have u a link?

I'm sorta keen to sort it out soon if u know what i mean...

Natbit

It's simply the way the author of PICALLW chose to describe what's happening, it's a perfectly normal term to use - just a bit frightening if you don't know what it really means.

My software does exactly the same thing, I just don't call it 'blowing the fuses', modern, more accurate, terminology would be 'setting the configuration word'.

As for your problem with WinPicProg, have you got it set to use the correct version of the P16PRO40? - there are two variations, one uses an inverting buffer, the other uses a non-inverting buffer. You can select the two options from the pulldown menu on the hardware screen.

 

[natbit]

Thanks Nigel

 

[Jimmy Vivas]

I am having the same problem with Address 0000h

Nigel,

I took the plunge and am left stranded, I keep getting the ubiquitous

"Program verify failed at program address 0x000, programming aborted!"

I followed the FAQ and am pulling 12.8 V across MCLR, this should be enough for that particular problem, no?

:shock:

Hi I am Jimmy from vzla. The thing, I am having the same problem with the verify error at address 0000h. How could I solve this problem. Please I need the answer

 

[natbit]

Jimmy my problen was simply the inverted nature of my programmer, even though I had 12.8 V across MCLR and gnd the logic states were wrong. Nigel is saying that I should change the logic state in 'Hardware Settings'. I havn't done this myself 'cause I went back to PICALLW but I will need to when I use 16F628.