Programming 18Fxxx series

[Jon Fick]

I've searched the archives for an answer but I suspect many more people are trying to build things with PICs rather than build a programmer to program PICs! I do both...

I'm trying to add the 18F252 and 18F452 to my programmer software and hardware. (See www.VermontFicks.org/pic.htm)

* The hardware doesn't require any changes. For instance, the 16F876 and the 18F252 are identical in programming pinout, voltages, etc.
* The software (DOS-based) changes radically from the 16F series. Thus far I've got the 18F252 bulk erasing, and programming (to an extent, I think) but reading back seems to show that only some areas are being programmed (or read back.) I've gone through the basics to narrow down whether the problem is in writing or reading, and have gotten down to a bit-by-bit step through the sequence and observing with an oscilloscope, as well as radically slowing timing to avoid any possible critical races. All of this is an attempt to follow Microchip's programming document to the letter.

Past experience has shown me that developing the software is laborious, but once it works, it works flawlessly. (Naturally!) I'm just not at that point yet.

Has anyone attempted to deal with programming the 18Fxx2 series at this level? Are there any caveats you can share? Any errors in Microchip's document? (I found one.)

Thanks for any help.

Jon Fick
www.VermontFicks.org/pic.htm
___________________________
This message was ported from CCS's old forum
Original Post ID: 13141

[Lance Lascari]

I recently did the same thing, added 18fxx2 support to my programmer. It actually went more smoothly by far than the 12f/16f stuff I had previously written... perhaps because these newer parts are more consistent with eachother in the programming aspect.

If you drop me an email I'll pass along the appropriate code if you want to have a look(a c++ class). I'm very happy with the 18fxx2 programming algorithm from microchip, it can run pretty fast....

Lance



:=I've searched the archives for an answer but I suspect many more people are trying to build things with PICs rather than build a programmer to program PICs! I do both...
:=
:=I'm trying to add the 18F252 and 18F452 to my programmer software and hardware. (See www.VermontFicks.org/pic.htm)
:=
:=* The hardware doesn't require any changes. For instance, the 16F876 and the 18F252 are identical in programming pinout, voltages, etc.
:=* The software (DOS-based) changes radically from the 16F series. Thus far I've got the 18F252 bulk erasing, and programming (to an extent, I think) but reading back seems to show that only some areas are being programmed (or read back.) I've gone through the basics to narrow down whether the problem is in writing or reading, and have gotten down to a bit-by-bit step through the sequence and observing with an oscilloscope, as well as radically slowing timing to avoid any possible critical races. All of this is an attempt to follow Microchip's programming document to the letter.
:=
:=Past experience has shown me that developing the software is laborious, but once it works, it works flawlessly. (Naturally!) I'm just not at that point yet.
:=
:=Has anyone attempted to deal with programming the 18Fxx2 series at this level? Are there any caveats you can share? Any errors in Microchip's document? (I found one.)
:=
:=Thanks for any help.
:=
:=Jon Fick
:=www.VermontFicks.org/pic.htm
___________________________
This message was ported from CCS's old forum
Original Post ID: 13143

[John Yaron]

:=I recently did the same thing, added 18fxx2 support to my programmer. It actually went more smoothly by far than the 12f/16f stuff I had previously written... perhaps because these newer parts are more consistent with eachother in the programming aspect.
:=
:=If you drop me an email I'll pass along the appropriate code if you want to have a look(a c++ class). I'm very happy with the 18fxx2 programming algorithm from microchip, it can run pretty fast....
:=
:=Lance
:=
:=
:=
:=:=I've searched the archives for an answer but I suspect many more people are trying to build things with PICs rather than build a programmer to program PICs! I do both...
:=:=
:=:=I'm trying to add the 18F252 and 18F452 to my programmer software and hardware. (See www.VermontFicks.org/pic.htm)
:=:=
:=:=* The hardware doesn't require any changes. For instance, the 16F876 and the 18F252 are identical in programming pinout, voltages, etc.
:=:=* The software (DOS-based) changes radically from the 16F series. Thus far I've got the 18F252 bulk erasing, and programming (to an extent, I think) but reading back seems to show that only some areas are being programmed (or read back.) I've gone through the basics to narrow down whether the problem is in writing or reading, and have gotten down to a bit-by-bit step through the sequence and observing with an oscilloscope, as well as radically slowing timing to avoid any possible critical races. All of this is an attempt to follow Microchip's programming document to the letter.
:=:=
:=:=Past experience has shown me that developing the software is laborious, but once it works, it works flawlessly. (Naturally!) I'm just not at that point yet.
:=:=
:=:=Has anyone attempted to deal with programming the 18Fxx2 series at this level? Are there any caveats you can share? Any errors in Microchip's document? (I found one.)
:=:=
:=:=Thanks for any help.
:=:=
:=:=Jon Fick
:=:=www.VermontFicks.org/pic.htm

Hey Jon
I'll be going down that road very soon. I have to mod
my 16F programming/test device (which flashes and tests my
products) to support 18F. When I start. I'll post any
issues I hit.

What uChip doc error did you find?

John
___________________________
This message was ported from CCS's old forum
Original Post ID: 13175

[Jon Fick]

:=Hey Jon
:=I'll be going down that road very soon. I have to mod
:=my 16F programming/test device (which flashes and tests my
:=products) to support 18F. When I start. I'll post any
:=issues I hit.
:=
:=What uChip doc error did you find?
:=
:=John

John,

Page 12 of the PDF doc, Programming Specification DS39576B, in Table 3-4 "Write Code Memory Sequence", Step 1, third instruction. It reads "BSF EECON1, WREN" which expects to set the WREN bit (bit 2) high in the EECON1 register. The opcode is listed as 86; I think it should be 84.

Please correct me if I'm wrong. Thankfully, I hardly deal with assembly language any more, this being the CCS C Forum!

Jon
___________________________
This message was ported from CCS's old forum
Original Post ID: 13200

[Tomi]

<font face="Courier New" size=-1>Well, I have done this a couple of months ago. My programmer currently "eats" everything from 12C to 18F series.
The main basic thing about PIC18 family is that you must pay attention to hold the CLOCK line high after the last data byte sent in a programming cycle.
Here are some of my functions; note that I have implemented a binary protocol instead of getting a HEX file. The "Host_receive()" function reads the next byte from the serial buffer or waits for the next one (with timeout) if the buffer is empty.
"Host_transmit()" is a "putch(inbyte)" plus checksum calculation.

void Out4bitCommand(char be) // send a 4-bit command to PIC
{
char i;

for (i=0;i<4;i++) {
if (bit_test(be,0)) output_high(DATA);
else output_low(DATA);
output_high(CLOCK);
Restart_wdt();
output_low(CLOCK);
be >>= 1;
}
output_low(DATA);
}

void Out4bitCommandH(char be) // send a 4-bit command to PIC hold CLOCK high
{
char i;

for (i=0;i<4;i++) {
if (bit_test(be,0)) output_high(DATA);
else output_low(DATA);
output_high(CLOCK);
Restart_wdt();
if (i<3) output_low(CLOCK);
be >>= 1;
}
output_low(DATA);
}

void Out8bitCommand(char be) // send a 8-bit command to PIC
{
char i;

for (i=0;i<8;i++) {
if (bit_test(be,0)) output_high(DATA);
else output_low(DATA);
output_high(CLOCK);
Restart_wdt();
output_low(CLOCK);
be >>= 1;
}
output_low(DATA);
}

void OutData(unsigned long be) // send 16-bit data to PIC
{
char i;

for (i=0;i<16;i++) {
if (bit_test(be,0)) output_high(DATA);
else output_low(DATA);
output_high(CLOCK);
Restart_wdt();
output_low(CLOCK);
be >>= 1;
}
output_low(DATA);
}

#separate
unsigned long InputData() // get 16-bit data from PIC
{
char i;
unsigned long ki;

input(DATA);
ki = 0;
for (i=0;i<16;i++) {
output_high(CLOCK);
ki >>= 1;
output_low(CLOCK);
if (input(DATA)) bit_set(ki,15);
else bit_clear(ki,15);
}
output_low(DATA);
return ki;
}

#separate
char Input8bitData() // get 8-bit data from PIC
{
char i;
char ki;

input(DATA);
ki = 0;
for (i=0;i<8;i++) {
output_high(CLOCK);
output_low(CLOCK);
ki >>= 1;
if (input(DATA)) bit_set(ki,7);
else bit_clear(ki,7);
}
//output_low(DATA);
return ki;
}

void OutP18Command(char comm,char d1,char d2)
{
Out4bitCommand(comm);
Out8bitCommand(d2); // send out reverse order
Out8bitCommand(d1);
}

void DoReadCode()
{
char leng;
char addressL,addressH,addressX;
char be;

addressL = HOST_Receive(); // get the 24-bit address
addressH = HOST_Receive();
addressX = HOST_Receive();
leng = HOST_Receive(); // get the requested length (1-255)
chksum = 0;
do {
OutP18Command(0,0x0E,addressX);
OutP18Command(0,0x6E,0xF8);
OutP18Command(0,0x0E,addressH);
OutP18Command(0,0x6E,0xF7);
OutP18Command(0,0x0E,addressL);
OutP18Command(0,0x6E,0xF6);
Out4bitCommand(0x09);
Out8bitCommand(0);
be = Input8bitData();
Host_Transmit(be);
if (!(addressL++)) addressH;
} while (--leng);
Host_Transmit(chksum);
}

void DoReadData() // read in data EEPROM
{
char leng;
char address;
unsigned long be;
#byte beH = be+1

address = HOST_Receive(); // address of the first byte
leng = HOST_Receive(); // data length 0:full 256 byte area
chksum = 0;
do {
OutP18Command(0,0x9E,0xA6);
OutP18Command(0,0x9C,0xA6);
OutP18Command(0,0x0E,address);
OutP18Command(0,0x6E,0xA9);
OutP18Command(0,0x80,0xA6);
OutP18Command(0,0x50,0xA8);
OutP18Command(0,0x6E,0xF5);
Out4bitCommand(0x02);
be = InputData();
Host_Transmit(beH); // just the upper byte is valid!
} while (--leng);
Host_Transmit(chksum);
}

void DoBulkCode() // this is NOT for code (bad name): actually bulk erase the entire chip !!!
{
OutP18Command(0,0x0E,0x3C);
OutP18Command(0,0x6E,0xF8);
OutP18Command(0,0x0E,0x00);
OutP18Command(0,0x6E,0xF7);
OutP18Command(0,0x0E,0x04);
OutP18Command(0,0x6E,0xF6);
OutP18Command(0x0C,0x00,0x80);
OutP18Command(0,0,0);
Out4bitCommand(0);
output_low(CLOCK);
delay_ms(6);
Out8bitCommand(0);
Out8bitCommand(0);
}

void DoWriteCode()
{
char addressL,addressH,addressX;
char i,bdata[8];

addressL = HOST_Receive(); // get the 24-bit address
addressH = HOST_Receive();
addressX = HOST_Receive();
for (i=0;i<8;i++)
bdata[i] = HOST_Receive(); // receive 8 code bytes
OutP18Command(0,0x0E,0x3C);
OutP18Command(0,0x6E,0xF8);
OutP18Command(0,0x0E,0x00);
OutP18Command(0,0x6E,0xF7);
OutP18Command(0,0x0E,0x06);
OutP18Command(0,0x6E,0xF6);
OutP18Command(0x0C,0x00,0x00);
OutP18Command(0x00,0x8E,0xA6);
OutP18Command(0x00,0x9C,0xA6);
OutP18Command(0x00,0x0E,addressX);
OutP18Command(0,0x6E,0xF8);
OutP18Command(0x00,0x0E,addressH);
OutP18Command(0,0x6E,0xF7);
OutP18Command(0x00,0x0E,addressL);
OutP18Command(0,0x6E,0xF6);
OutP18Command(0x0D,bdata[1],bdata[0]);
OutP18Command(0x0D,bdata[3],bdata[2]);
OutP18Command(0x0D,bdata[5],bdata[4]);
OutP18Command(0x0F,bdata[7],bdata[6]);
Out4bitCommandH(0);
delay_us(1200);
output_low(CLOCK);
delay_us(12);
Out8bitCommand(0);
Out8bitCommand(0);
}

void DoWriteData() // write one byte into data EEPROM
{
char addr,bdata;

addr = HOST_Receive(); // address of EEPROM
bdata= HOST_Receive(); // data to program
OutP18Command(0x00,0x9E,0xA6);
OutP18Command(0x00,0x9C,0xA6);
OutP18Command(0x00,0x0E,addr);
OutP18Command(0x00,0x6E,0xA9);
OutP18Command(0x00,0x0E,bdata);
OutP18Command(0x00,0x6E,0xA8);
OutP18Command(0x00,0x84,0xA6);
OutP18Command(0x00,0x0E,0x55);
OutP18Command(0x00,0x6E,0xA7);
OutP18Command(0x00,0x0E,0xAA);
OutP18Command(0x00,0x6E,0xA7);
OutP18Command(0x00,0x82,0xA6);
OutP18Command(0,0,0);
Out4bitCommand(0);
delay_ms(6);
Out8bitCommand(0);
Out8bitCommand(0);
OutP18Command(0x00,0x94,0xA6);
}

void DoWriteConfig()
{
char addre,i,bdata[14];

for (i=0;i<14;i++)
bdata[i] = HOST_Receive(); // receive the 14 byte config bytes

for (i=0;i<7;i++) {
addre = i<<1;
OutP18Command(0x00,0x0E,0x3C);
OutP18Command(0x00,0x6E,0xF8);
OutP18Command(0x00,0x0E,0x00);
OutP18Command(0x00,0x6E,0xF7);
OutP18Command(0x00,0x0E,0x06);
OutP18Command(0x00,0x6E,0xF6);
OutP18Command(0x0C,0x00,0x00);
OutP18Command(0x00,0x8E,0xA6);
OutP18Command(0x00,0x8C,0xA6);
OutP18Command(0x00,0x0E,0x30);
OutP18Command(0x00,0x6E,0xF8);
OutP18Command(0x00,0x0E,0x00);
OutP18Command(0x00,0x6E,0xF7);
OutP18Command(0x00,0x0E,addre);
OutP18Command(0x00,0x6E,0xF6);
OutP18Command(0x0F,bdata[addre+1],bdata[addre]);
Out4bitCommandH(0);
delay_ms(2);
output_low(CLOCK);
Out8bitCommand(0);
Out8bitCommand(0);
OutP18Command(0x00,0x2A,0xF6);
OutP18Command(0x0F,bdata[addre+1],bdata[addre]);
Out4bitCommandH(0);
delay_ms(2);
output_low(CLOCK);
Out8bitCommand(0);
Out8bitCommand(0);
}
}


Hope this helps.
Tomi

:=I've searched the archives for an answer but I suspect many more people are trying to build things with PICs rather than build a programmer to program PICs! I do both...
:=
:=I'm trying to add the 18F252 and 18F452 to my programmer software and hardware. (See www.VermontFicks.org/pic.htm)
:=
:=* The hardware doesn't require any changes. For instance, the 16F876 and the 18F252 are identical in programming pinout, voltages, etc.
:=* The software (DOS-based) changes radically from the 16F series. Thus far I've got the 18F252 bulk erasing, and programming (to an extent, I think) but reading back seems to show that only some areas are being programmed (or read back.) I've gone through the basics to narrow down whether the problem is in writing or reading, and have gotten down to a bit-by-bit step through the sequence and observing with an oscilloscope, as well as radically slowing timing to avoid any possible critical races. All of this is an attempt to follow Microchip's programming document to the letter.
:=
:=Past experience has shown me that developing the software is laborious, but once it works, it works flawlessly. (Naturally!) I'm just not at that point yet.
:=
:=Has anyone attempted to deal with programming the 18Fxx2 series at this level? Are there any caveats you can share? Any errors in Microchip's document? (I found one.)
:=
:=Thanks for any help.
:=
:=Jon Fick
:=www.VermontFicks.org/pic.htm ___________________________
This message was ported from CCS's old forum
Original Post ID: 13207

[John Yaron]

:=:=Hey Jon
:=:=I'll be going down that road very soon. I have to mod
:=:=my 16F programming/test device (which flashes and tests my
:=:=products) to support 18F. When I start. I'll post any
:=:=issues I hit.
:=:=
:=:=What uChip doc error did you find?
:=:=
:=:=John
:=
:=John,
:=
:=Page 12 of the PDF doc, Programming Specification DS39576B, in Table 3-4 "Write Code Memory Sequence", Step 1, third instruction. It reads "BSF EECON1, WREN" which expects to set the WREN bit (bit 2) high in the EECON1 register. The opcode is listed as 86; I think it should be 84.
:=
:=Please correct me if I'm wrong. Thankfully, I hardly deal with assembly language any more, this being the CCS C Forum!
:=
:=Jon

Jon

wow... you actually peruse the opcode column...
isn't that why we spend hard earned money on these
overpriced compilers so as to not bother with the
mundane aspects of outputting machine opcode.

Thanks for the heads up.

John
___________________________
This message was ported from CCS's old forum
Original Post ID: 13230