Problems with programming PIC 16F648A

[Jan Panteltje]

I have some strange problems wit h16F648 A, cannot seem to program it
right both in high voltage and low voltage mode.
Whenever I write a 000 to addrss 0 (to test) I get 2000.
Other locations do nothing (stay 3fff).
So I did a google and found also EEPROM problems, and several errata,
voltage problems and what not, but not this problem.
Bulk erase seems to work, checked all timings and setup, I would think dead
PIC but I have 2 and both do the same.
(Other PICS program OK on the same programmer (I made aha).
Since I already made a board and need the UART and it is sunday
cannot get an other one NOW, anyone had this problem?
Jan

 

[Tim Dicus]

I have some strange problems wit h16F648 A, cannot seem to program it
right both in high voltage and low voltage mode.
Whenever I write a 000 to addrss 0 (to test) I get 2000.
Other locations do nothing (stay 3fff).
So I did a google and found also EEPROM problems, and several errata,
voltage problems and what not, but not this problem.
Bulk erase seems to work, checked all timings and setup, I would think dead
PIC but I have 2 and both do the same.
(Other PICS program OK on the same programmer (I made aha).
Since I already made a board and need the UART and it is sunday
cannot get an other one NOW, anyone had this problem?
Jan

Hi Jan,

I have had that challenge with other PIC processors before, but not this particular model.

My challenge was created by inadvertently setting the "code protect" feature. Bulk erase (even UV erase on other models) no longer
clears these functions. On older models it did. On the newer versions, once they are activated, I have found no way of disabling
them. Microchip said it was a way hackers were using to get around the code protect feature.

Writing zeros to CONFIG (configuration word) at location 2007 in your model, would activate this feature. Insure you do not clear
bit7 (CP) and bit8 (CPD) until the IC is programmed the way you want it, then don't attempt to program it again. Otherwise, all is
lost.

Hope that helps,

Tim

 

[Wouter van Ooijen]

(Other PICS program OK on the same programmer (I made aha).

Did you have success with PICs with the same programming algorithm
(16F627A, 16F628A)?

NB my programmer has no problem with a 16F648A.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Jan Panteltje]

Did you have success with PICs with the same programming algorithm
(16F627A, 16F628A)?

NB my programmer has no problem with a 16F648A.


Wouter van Ooijen

Hi, I had a look at the code you use for your programmer 'wisp'
on you site.
I could prog it in a 16F648 (= only more space then 16F628), if only
it would prog .
I see you sell surplus stuff, are the chips you sell reject batches or
official microchip output?

Is not the programming algo the same for 16F648 as 16F84?
(I mean 6 bits command, 14 bits data etc.. the works? ), some
us delay..

 

[Byron A Jeff]

-On a sunny day (Sun, 08 Feb 2004 16:12:17 GMT) it happened [email protected]
-(Wouter van Ooijen (www.voti.nl)) wrote in
-<[email protected]>:
-
-Is not the programming algo the same for 16F648 as 16F84?
-(I mean 6 bits command, 14 bits data etc.. the works? ), some
-us delay..
-

Nope. The erasure algorithm is definitly different. It's always best to go over
The programming specifications with a fine toothed comb when moving to a new
chip.

BAJ (who has this chip on his update list for picprg3.0alpha)

 

[Jan Panteltje]

-Is not the programming algo the same for 16F648 as 16F84?
-(I mean 6 bits command, 14 bits data etc.. the works? ), some
-us delay..
-

Nope. The erasure algorithm is definitly different. It's always best to go over
The programming specifications with a fine toothed comb when moving to a new
chip.

Yes, but the erase it the part that works
I tried looking for the SPECIFIC program specifications for this chip, but not found,
what name datasheet are you using?

 

[Jan Panteltje]

-Is not the programming algo the same for 16F648 as 16F84?
-(I mean 6 bits command, 14 bits data etc.. the works? ), some
-us delay..

Never mid, I found the programming spec, BTW I did that other erase procedure for
the 12F6xx
This is a mod to noppp_lx (Linux) I did last year:

void Derase()
{
int a, i;


vppreset();// Vpp now ON!!!,
// and has been 25000 uS because of delay in vppreset.

printf("Commanding PIC to erase ID, configuration\n");

/*
From Microchip pdf
Read and store OSCCAL and BG bits
Execute Load Configuration000000
Execute Bulk Erase Program Memory001001 (will also erase data memory of !CPD was 0)
Wait Tera
Execute Bulk Erase Data Memory0010011
Wait Tera
Reset device to RESET address counter before re-programming device
Restore OSCCAL and BG bits
*/

/* read osccal from program memory 0x03ff OSCCAL in bank 1 address 0x90 */
/* move up in program address space */
i = 0;
while(1)
{
sendcmd(READPROGRAM);
a = recvdata();
if(i == 0x03ff)
{
osccal = a & 0xff; // 8 bits register */
break;
}

sendcmd(INCREMENTADDRESS);
i++;
}
fprintf(stdout, "i=0x%04x a=0x%03x osccal=0x%04x\n", i, a, osccal);


/* read bandgap bits */
sendcmd(LOADCONFIG);
// prog counter now at 0x2000

//senddata(DEFAULTCONFIG); // loadconfig requires an arg, here it is

/* read 7 words from 0x2000 up */
sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2000=0x%03x ID LOCATION\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2001=0x%03x ID LOCATION\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2002=0x%03x ID LOCATION\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2003=0x%03x ID LOCATION\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2004=0x%03x NOT USED\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2005=0x%03x NOT USED\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2006=0x%03x DEVICE ID (PIC12F629=0x00f4, PIC12F675=0x00f6)\n", a);
sendcmd(INCREMENTADDRESS);

sendcmd(READPROGRAM);
a = recvdata();
fprintf(stdout, "CONFIG MEMORY 0x2007=0x%03x CONFIGURATION BITS\n", a);
sendcmd(INCREMENTADDRESS);

bandgap1 = (a >> 13) & 1;
bandgap0 = (a >> 12) & 1;

fprintf(stdout, "bandgap0=%d (BG0)\n", bandgap0);
fprintf(stdout, "bandgap1=%d (BG1)\n", bandgap1);

/* erase all */
sendcmd(LOADCONFIG);
// prog counter now at 0x2000

senddata(0x3FFF);
for (i = 7; i > 0; i--) sendcmd(INCREMENTADDRESS);

sendcmd(ERASEPROGRAM);
usleep(10000);

sendcmd(ERASEDATA);
usleep(10000);

allpinslow();

fprintf(stdout, "Done.\n");
} /* end function erase */


Not sure it makes sense to you.
For what it is worth, all 12F6xx are working.

Tomorrow perhapos I will have a go with the specs I just found.
JP

 

[Wouter van Ooijen]

Hi, I had a look at the code you use for your programmer 'wisp'

That is the old one, better look at the Wisp628

I see you sell surplus stuff, are the chips you sell reject batches or
official microchip output?

I make a clear distinction on all items: either surplus (mentioned in
the description) or new. All PICs are new.

Is not the programming algo the same for 16F648 as 16F84?
(I mean 6 bits command, 14 bits data etc.. the works? ), some
us delay..

Yes, but the commands do differ. 16F84, 16F87x and 16F62x are almost
the same, 16F62xA is different (and 16F87xA is yet another group). The
16F648 does not exist, 16F648A does and falls in the latter group.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Jan Panteltje]

That is the old one, better look at the Wisp628


I make a clear distinction on all items: either surplus (mentioned in
the description) or new. All PICs are new.


Yes, but the commands do differ. 16F84, 16F87x and 16F62x are almost
the same, 16F62xA is different (and 16F87xA is yet another group). The
16F648 does not exist, 16F648A does and falls in the latter group.


Wouter van Ooijen

OK, some 16F648 AAAAA will be ordered from you soon.
Have it all working now, I get the prog signals from the PC
par port, and will add an extra signal to 'short' (in my case iterrupt) Vdd.
See my other post on subject Microchip.
Since there is no max time, the task switch and interrupt on the PC
pose no problems to do it with the par port.
Also because that leaves a serial port free (and so no -through- mode needed),
but 4 sure I will perhaps prog wisp in one to try that.
Thank you

 

[Jan Panteltje]

Well, after one (just one) look at the datasheet for programming
the 16F648A it was clear what the problem was.
This PIC wants Vdd off BEFORE Vpp ..... is applied.
Since this was an attempt to (the much advertized) in circuit programming,
of cause Vdd was on all the time, and teh xatl osc running duh.
Now has Microchip lost its marbles?

HOW can you do this?
Wouter solved it by shorting Vdd to ground by a transistor I noticed.
That may not be so good if the PIC is run from a 50A 5V supply, but Wouter
uses current limit in that transistor.
The 16F84 COULD be programmed without the Vdd requirement.
So Microchip must have lost some marbles?
Do I see this right?
WHY do they do this?

It is no great deal to implement a Vdd switch, or put a series resistor on the
board for this though ONCE YOU KNOW IT.
But the whole thing sucks also because they offer an IO pin for low voltage
programming, AND STILL need Vdd low to start.

Why pester your users by making this sort of changes?
Not good for customer relations.
JP

 

[Wouter van Ooijen]

Well, after one (just one) look at the datasheet for programming

the 16F648A it was clear what the problem was.
This PIC wants Vdd off BEFORE Vpp ..... is applied.
Since this was an attempt to (the much advertized) in circuit programming,
of cause Vdd was on all the time, and teh xatl osc running duh.
Now has Microchip lost its marbles?

I would say you have lost some marbles. You seriously expected your
programmer to program a chip without even looking at the programming
specifications?

So Microchip must have lost some marbles?

Two notes:

This new sequence was required because the MCLR pin can be decoupled
from the MCLR function.

In my experience nearly all PICs that officially require
Vpp-before-Vdd can be programmed without switching Vdd, untill you
enable the MCLR pin as I/O (actually: I). This is of course
out-of-spec, so YMMV.

But the whole thing sucks also because they offer an IO pin for low voltage
programming, AND STILL need Vdd low to start.

same reason as for HVP: MCLR could be an input pin.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Jan Panteltje]

I would say you have lost some marbles. You seriously expected your
programmer to program a chip without even looking at the programming
specifications?

Oh but I looked for those, and those without marbles referred to ds41196
and a google for that or even search via their (microchip's own site) returns
nothing.
This is because that document actually is called 41196e.pdf
So now microchip has some less (and they change these things with every
bug fix of their chip, for 41196a all the way through e now).
So f*ck them.

This new sequence was required because the MCLR pin can be decoupled
from the MCLR function.

In my experience nearly all PICs that officially require
Vpp-before-Vdd can be programmed without switching Vdd, untill you
enable the MCLR pin as I/O (actually: I). This is of course
out-of-spec, so YMMV.

Well I found out the real reason, as I said, it programmed OK in the
programmer (with my soft mod for erase), but not in serial.
The reason was 50 cm flat cable I used the clock was next to the data.
So I put Vdd between data and clock and all started working.
Next was that officially PGM must be zero initially (as LVP mode).
I did check for zero with voltmeter and 10x scope probe, and it was.
Then I found it would program only if scope probe on pin....
Capacitance? well I put a 47 kOhm resistor to ground and then everything
worked. And it is internal in the PIC, as there is nothing on that pin, and
pull-ups disabled).
OK, well at least I can work now on programming it.
The fact that MCLR is not used makes it possible to serial prog and test
without a special switch (12 V / 5 V / ground).

As for the wisp, I will try to port the programmer to USB with the FT245BM.
But I only found a Linux client for the 232 chip, so not sure if that is
easy.
Did you ever come across a Linux client for the FT245BM?

One thing you could try with a PIC a la wisp is make a PWM , lowpass, and
drive into a CMOS opamp (rail to rail) to make a programmer that can work at
any Vdd.
As I generate all sequences on teh PC for programming and control, only one
FT245 should work I think.
This is a big advantage, only the hardware layer needs updating.
So you have routines for vppon vppof vddon vddoff etc..
Just pin jingling.
JP

 

[Wouter van Ooijen]

So now microchip has some less (and they change these things with every

bug fix of their chip, for 41196a all the way through e now).
So f*ck them.

? I useed the very first programming specs for the 16F628A and this
still works for all 16F62xA chips I try.

As for the wisp, I will try to port the programmer to USB with the FT245BM.
But I only found a Linux client for the 232 chip, so not sure if that is
easy.
Did you ever come across a Linux client for the FT245BM?

Why not use the FT232BM?


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Jan Panteltje]

? I useed the very first programming specs for the 16F628A and this
still works for all 16F62xA chips I try.

Well it is microchips errata, and for the A you can google for the sleep
problem too.

Why not use the FT232BM?

Because I want to use bit-bang mode, no not driving a PIC, the pins of the
FT245BM will drive the PIC to be programmed (algo on PC side).
Some extra logic perhaps.
Also I may try the 245 as interface to FPGA
JP

 

[Wouter van Ooijen]

Why not use the FT232BM?

Because I want to use bit-bang mode, no not driving a PIC, the pins of the
FT245BM will drive the PIC to be programmed (algo on PC side).
Some extra logic perhaps.
Also I may try the 245 as interface to FPGA

Bit-bang mode is available on both chips, but AFAIK it requires the
non-VCP drivers and only the VCP drivers are available for Linux.



Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
PICmicro chips, programmers, consulting

 

[Lasse Langwadt Christensen]

Well it is microchips errata, and for the A you can google for the sleep
problem too.




Because I want to use bit-bang mode, no not driving a PIC, the pins of the
FT245BM will drive the PIC to be programmed (algo on PC side).
Some extra logic perhaps.
Also I may try the 245 as interface to FPGA
JP

FT232BM can do bitbang as well I believe.

Have you checked if the linux client also works with ft245, from the
hostside I'm not sure theres much difference ?
I've only used it on windows so...


-Lasse

 

[Jan Panteltje]

Bit-bang mode is available on both chips, but AFAIK it requires the
non-VCP drivers and only the VCP drivers are available for Linux.



Wouter van Ooijen

I just found ftdi_sio_tj.tar.gz, it says bit bang mode supported now.
Not sure, tried to compile it, but 1832 error messages.
This is for later

 

[Jan Panteltje]

FT232BM can do bitbang as well I believe.

Have you checked if the linux client also works with ft245, from the
hostside I'm not sure theres much difference ?
I've only used it on windows so...

Hi, I am trying to compile the Linux client side, so far no luck.
Just got the chip, so it will take a while to get the whole setup
working (have to make a PCB etc...).
JP