[16F18xxx & 152xx] OPGUI cannot write configuration registers1-5

[Dan Skareda]

Great project by the programmer, I commend it. Unfortunately, for a whole series of circuits that have configuration registers CONFIG1-5 at ICSP addresses 0x8007-0x800B, when I try to program (I program with skip 3V3 regulator check, because I'm powering the circuit with 5V - I have MCLR/VPP, VDD, GND, ICSPDAT, ICSPCLK wires connected to the chip) the circuit, I get this message:

Code memory:
0000: 3180 2802 3187 2FFD FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
07E0: FFFF FFFF FFFF FFFF FFFF FFFF FFFF 306A 0151 008E 017E 01B8 0140 1112 1118 3004 0140 0698 3003
07F0: 00F1 308A 00F0 3056 0B89 2FF4 0BF0 2FF4 0BF1 2FF4 2FEC 3180 2802 0140 3187 2FE4
8000: FFFF FFFF FFFF FFFF FFFF FFFF FFFF 3FCD 3FE6 FFFF 1FFF

Can't find CONFIG location (0x8007-0x800B)
End

However, the programmer will perform the circuit reading function (hopefully) without error. This applies to circuits 16F15214, 16F15355 or 16F13115, and probably also 16F18026 and 16F18014. I don't know if I have an incorrect configuration in the program, or if it is an error in opgui.exe, but MPLAB X IDE compiled the program without errors. With circuits of other series, e.g. 10F322 or 12F509, the programmer has no problem, because these circuits do not have configuration registers at the specified addresses. I sent the details to the author by e-mail.

Addendum: When trying to program 12F1572, the programmer writes exactly the same message "Can't find CONFIG location (0x8007-0x800B)", even though the code does not contain this address and this address is not listed in the datasheet.

[Dan Skareda]

With great effort I found out that the problem is in MPLAB X IDE, which did not transfer the configuration bytes to the generated HEX file, although I define them using PRAGMA. I don't know why. The programmer expects them in the HEX file. Somehow I finally managed to get them there and programmed the circuit, so now the LED connected to RA2 is blinking. However, the program op.exe (it is the same in opgui.exe) prints this while programming:

D:\data\openprogrammerPIC>op -d 16F15214 -w blink.hex -nolvcheck
Programmer detected
Firmware version 0.12.0
Hardware ID: 0.0.4 (18F25K50)

[1] blink.hex :

Code memory:
0000: 3180 2802 3187 2FFD FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
07E0: FFFF FFFF FFFF FFFF FFFF 306A 0151 008E 017E 01B8 0140 1112 1118 3004 0140 0698 3003
07F0: 00F1 308A 00F0 3056 0B89 2FF4 0BF0 2FF4 0BF1 2FF4 2FEC 3180 2802 0140 3187 2FE4
8000: FFFF FFFF FFFF FFFF FFFF FFFF FFFF 3FCD 3FE6 FFFF 1FFF 3FFF

Regulator up and running after 0ms VPP=8.4V

Regulator up and running after 0ms VPP=8.5V

DevID: 0x30E6
DevREV: 0x2008
16F15214
Device Information Area @0x8100
8100: 0042 0031 0083 0001 0052 0041 0030 0013 0010 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
8110: 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 0401 0804 1003 0000 0000 0000 3FFF 3FFF
Device Configuration Information @0x8200
8200: 0020 0020 0080 0000 0008 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
8210: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Erase row size: 32 words
Write latches: 32
User rows: 128
->4096 Flash words
EE data memory size: 0
Pin count: 8
Erasing ... completed
Writing code ... completed
Verifying code ... Error writing address 0: written 3180, read 0000
Error writing address 1: written 2802, read 0000
Error writing address 2: written 3187, read 0000
Error writing address 3: written 2FFD, read 0000
Error writing address 4: written 3FFF, read 0000
Error writing address 5: written 3FFF, read 0000
Error writing address 6: written 3FFF, read 0000
Error writing address 7: written 3FFF, read 0000
Error writing address 8: written 3FFF, read 0000
Error writing address 9: written 3FFF, read 0000
Error writing address A: written 3FFF, read 0000
Error writing address B: written 3FFF, read 0000
Error writing address C: written 3FFF, read 0000
Error writing address D: written 3FFF, read 0000
Error writing address E: written 3FFF, read 0000
Error writing address F: written 3FFF, read 0000
Error writing address 10: written 3FFF, read 0000
Error writing address 11: written 3FFF, read 0000
Error writing address 12: written 3FFF, read 0000
Error writing address 13: written 3FFF, read 0000
Error writing address 14: written 3FFF, read 0000
completed, 21 errors
Writing CONFIG area ...
completed, 0 errors

End (0.28 s) 21 errors

Why couldn't the programmer write data from address 0? I use these voltages - Vdd=5V, Vpp=8.5V (set by programmer), noLVcheck.

My config:

// CONFIG1
#pragma config FEXTOSC = OFF    // External Oscillator Mode Selection bits (Oscillator not enabled)
#pragma config RSTOSC = HFINTOSC_32MHZ// Power-up Default Value for COSC bits (HFINTOSC (32 MHz))
#pragma config CLKOUTEN = OFF   // Clock Out Enable bit (CLKOUT function is disabled; I/O function on RA4)
#pragma config VDDAR = HI       // VDD Range Analog Calibration Selection bit (Internal analog systems are calibrated for operation between VDD = 2.3V - 5.5V)

// CONFIG2
#pragma config MCLRE = INTMCLR  // Master Clear Enable bit (If LVP = 0, MCLR pin is port defined function; If LVP = 1, RA3 pin function is MCLR)
#pragma config PWRTS = PWRT_OFF // Power-up Timer Selection bits (PWRT is disabled)
#pragma config WDTE = OFF       // WDT Operating Mode bits (WDT disabled; SEN is ignored)
#pragma config BOREN = ON       // Brown-out Reset Enable bits (Brown-out Reset Enabled, SBOREN bit is ignored)
#pragma config BORV = LO        // Brown-out Reset Voltage Selection bit (Brown-out Reset Voltage (VBOR) set to 1.9V)
#pragma config PPS1WAY = ON     // PPSLOCKED One-Way Set Enable bit (The PPSLOCKED bit can be set once after an unlocking sequence is executed; once PPSLOCKED is set, all future changes to PPS registers are prevented)
#pragma config STVREN = ON      // Stack Overflow/Underflow Reset Enable bit (Stack Overflow or Underflow will cause a reset)

// CONFIG3

// CONFIG4
#pragma config BBSIZE = BB512   // Boot Block Size Selection bits (512 words boot block size)
#pragma config BBEN = OFF       // Boot Block Enable bit (Boot Block is disabled)
#pragma config SAFEN = OFF      // SAF Enable bit (SAF is disabled)
#pragma config WRTAPP = OFF     // Application Block Write Protection bit (Application Block is not write-protected)
#pragma config WRTB = OFF       // Boot Block Write Protection bit (Boot Block is not write-protected)
#pragma config WRTC = OFF       // Configuration Registers Write Protection bit (Configuration Registers are not write-protected)
#pragma config WRTSAF = OFF     // Storage Area Flash (SAF) Write Protection bit (SAF is not write-protected)
#pragma config LVP = OFF        // Low Voltage Programming Enable bit (High Voltage on MCLR/Vpp must be used for programming)

// CONFIG5
#pragma config CP = OFF         // User Program Flash Memory Code Protection bit (User Program Flash Memory code protection is disabled)

[Alberto Maccioni]

Is the problem with op reproducible?
What do you read at those addresses?
The algorithm is exactly the same whether you use op or opgui; you could compare the log files to see when they diverge.

[Dan Skareda]

I probably expressed myself inaccurately, but op.exe and opgui.exe work the same way - both read the value zero at addresses close to zero (see my previous listing) from the 16F15214 circuit, as if the given area was locked against reading and writing. According to the CONFIG registers (see above), no area is locked. I try different settings, but it's the same thing repeatedly - addresses close to zero cannot be programmed or read. Is it because they were not previously erased by the programmer? I'm sending the log file to the author by email, because I'm not familiar with it.

Please also consider these observations:
- divide individual chips of the 16F series into 16F and 16LF so that 16F chips can be programmed 5V by default (without checking nolvcheck)
- if the hex code does not contain programming of addresses 0x8007-0x800B, the current program will end with an error (see my previous problem). Is it really necessary to program the CONFIGx registers every time? What if I don't want to change them, but only want to change the program?

[Dan Skareda]

I was wondering if there is a problem with Vpp. When programming older 12v circuits everything is fine, I have problems with Vpp 8.5v. Does the programmer check the Vpp voltage during programming? What if it does not stay at the desired level? I would add a low ESR capacitor to Vpp, but I am afraid that I will destroy the voltage generator...

[Alberto Maccioni]

You should try to read the devices after programming: how does it compare against the original hex file?
You can diagnose Vpp problems using the I/O tab; there you can set Vpp statically and measure it directly.
Vpp is checked before entering program mode; current PIC models do not rely on Vpp for supplying memory operations, so its value can vary a lot after program mode is entered.

[Dan Skareda]

If I set any voltage with the slider on the I/O card in opgui.exe (I still have "skip 3v3 regulator check" enabled) and then turn on VPPU, the resulting voltage is always only 4.7V, which is wrong. Is there a bug in opgui.exe? If I run the hardware test, the VPPU is the correct 12.9V (all pins have the correct voltage during the hardware test). If I start programming (I am currently programming a 16F13115), the program notifies me that 8.5V has been reached (depending on the type of circuit, this VPP for 16F13115 is correct) before it starts programming. All programmed bytes have 0xFF content after reading, which I found out by comparing two hex files (source and read) - it looks like nothing was programmed at all. The strange thing is that in the programming log I see that the 16F13115 circuit is being programmed as 16F18xxx:

OPGUI version 0.12.3 (Windows)

Firmware version 0.12.0
Wed Apr 02 17:38:49 2025

Write16F18xxx(8192,0,0)
StartHVReg(8,50)
PacketIO(5,00)
...

And it is also strange that in other places (where the programmer did not write) in the circuit there is already something programmed - this tells me that the circuit was not erased properly before programming.

[Alberto Maccioni]

In order to control the DCDC converter you need to enable I/O as well.
I just tried to write on a 15LF15325, which uses exactly the same algorithm, and I see no problems even at address 0.
Maybe you can send your hex file but I highly doubt the problem is file-related.

[Dan Skareda]

Thanks for trying to help me. I'm already unhappy about this, everything seems fine, but the programmer doesn't work. I turned on the VPPU+DCDC test according to your advice and when I set 8.5V, I measure 8.45V. When I program, the VPPU voltage appears at 8.5V, so that's probably fine too. The programmer flashes exactly at a 1 Hz rhythm, so the timing in 18F25K50 will probably be fine. When I program chips from the 10F and 12F series (i.e. with 5V on VDD and 12.5V on VPP), everything is fine (tested again today). The error is with all chips powered by 5V (I have the option checked "skip 3V3 regulator check"), which have VPPU 8.5V. Your chip is LF, so you power it with 3V3, but try programming a chip from the 16F1xxxx series as well and try it without the LV board. And try it with the 18F25K50 chip in the programmer without a crystal. This really seems like a software problem - a hardware specific configuration problem (18F25K50 + no LV board + 16F1xxxx)...

Reading the 16F13115 circuit seems to be working correctly (5V on VDD):

Regulator up and running after 0ms VPP=8.5V
Reading code ... completed
Reading CONFIG area ... completed
ID0: 0x3FFF ID1: 0x3FFF
ID2: 0x3FFF ID3: 0x3FFF
DevID: 0x3127
DevREV: 0x2002
16F13115
Configuration word 1: 0x3FFF
Configuration word 2: 0x3FFF
Configuration word 3: 0x3FFF
Configuration word 4: 0x3FFF
Configuration word 5: 0x3FFF
Device Information Area @0x8100
8100: 0042 0040 0092 0049 0001 0041 0038 0010 0000 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
8110: 3FFF 3FFF 3864 01AC 103A 3AF9 0282 101F 0401 0804 1008 0401 0805 1009 3FFF 3FFF
Device Configuration Information @0x8200
8200: 0020 0020 0100 0000 0008 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
8210: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
Erase row size: 32 words
Write latches: 32
User rows: 256
->8192 Flash words
EE data memory size: 0
Pin count: 8

Code memory:
(empty)

End (1.48 s)

I think it's an empty chip, so erase and write probably don't work in the programmer. I'm sending the contents of the HEX file I'm using to program the 16F13115 circuit:

:08000000803102288731FD2F39
:100FB800400112117D010C1140010C150B30F1009C
:100FC8002630F0005E30890BE72FF00BE72FF10B8E
:100FD800E72F40010C110B30F10 02630F0005E3095
:100FE800890BF42FF00BF42FF10BF42FE02F803145
:080FF800022840018731DC2FC3
:020000040001F9
:0A000E009C3FFE3FFF3FFF1FFF3F36
:00000001FF

My idea: If it's not a software problem, then the only thing that could possibly be causing the problem is the voltage stabilization after turning on VPP before programming - I can't measure it because I don't have an oscilloscope. Maybe the way to reach 8.5V is different than reaching 12.5V and that's why chips with lower VPP have a problem with erase+write, because the VPP voltage doesn't have time to stabilize before turning on VDD. Maybe an optional pause from turning on VPP to turning on VDD would solve this. Or slow down the erase/write process...

[Alberto Maccioni]

Well, I tried your file without 3.3V board using a 18F25K50 without crystal.
My 15LF15325 is written correctly, no errors.
The only difference is that you connect via ICSP.
Can you use the on-board socket?

[Dan Skareda]

I made a lv board, because I will try programming a 16F1xxxx with VPP=3V3, like you did. I don't have the PCB of open programmer exactly according to your design, but I designed it according to your schematic and everything important is preserved. I have a PIC16F13115 chip in SOIC8 design and it is connected to the programmer like this: 1-VDDU, 2-NC, 3-NC, 4-VPPU, 5-NC, 6-RB6(PGC), 7-RB5(PGM), 8-GND. I have built two programmers and both do the same thing - maybe I didn't choose the right components, but I chose them according to your recommendations (except for the inductance, for which I don't know what "resistor type" inductance is. So I used a 100uH, 660mA wirewound choke, resistance about 0.6ohm, type djnr6028-101-s and diode SKL15-DIO). As I wrote above, the programmer programs the 12F and 10F series and reads data from the 16F1xxxx series from read-only blocks probably correctly. So either the erase+programming method or the 8.5V generation method doesn't work. Or it's not possible to program circuits with VPP 8.5V at VDD 5V. I don't know, I'll do some more tests...

[Alberto Maccioni]

I guess you meant VDD=3.3V
Anyways, I tried also 5V and there is no problem with a 15LF15325.
So I would exclude algorithm related issues.
Your inductor is fine, it could be a lot worse and still work.
I didn't get if you already tried the on-board socket or not.

[Anonymous]

Oh, yes, VDD=3V3, sorry.
I connect the chips exactly the same way as the on-board socket is connected.
I will try to apply external voltage to the VPP line (hardware disconnect the internal oscillator) and then I will write if it worked.

[Dan Skareda]

I connect the chips like this:

[Alberto Maccioni]

If you have an oscilloscope you should see what happens during programming.

[Dan Skareda]

Oh yeah, an oscilloscope. Originally I thought I would just build a programmer. But now I'm slowly becoming an expert on PIC circuits. :-)

I made a third programmer with completely different transistors (because then there are only resistors) and I hoped that it would finally work. I reflashed the 18F25K50 with firmware 0.12.0 for the 18F25K50 and carefully checked that my "arduino LVP programmer" would verify the written data correctly. And yes, it did. When building the programmer, I did not connect the DCDC circuit, but brought an external 8.7V voltage to the VPP of the printed circuit board. Then I tried the "hardware test" and when everything was fine, I programmed the 16F13115 again. And nothing again. Still the same - it reads correctly (I verified the read default data according to the datasheet), but it does not erase or write.

I am sure the chip will not go into HVP state. Can you add the LVP programming option to opgui.exe? I looked at the program and the code is ready for it... I could use that to verify that the programming sequence is correct.

It is also possible that the opgui.exe program does not time correctly in Windows 11 home, because there is some timing there. That is why it works for you and not for me...

(from datasheet)
High-Voltage Programming Entry Mode:
The device is placed into High-Voltage Programming Entry mode by holding the ICSPCLK and ICSPDAT pins low, then raising the voltage on MCLR/VPP to VIH......

[Alberto Maccioni]

If you see the device model it certainly entered program mode; from your logs I see it does.
The programmer is designed in order not to rely on computer timing.
It could be that support for 16F13115 contains a bug, after all I did not directly verify it; on paper it seems exactly the same as 16LF15325.
Can you try a different model?

[Dan Skareda]

I tried these chips:
OK - 10f322, 12f509
Error (does not write) - 16f13115, 16f15214, 16f15355
I did not try, but I have (I am afraid to destroy it, because I do not know what the problem is with the programmer): 16f18014, 16f18026, 18f16q41, 18f25k50.
I am considering ordering: 16lf1705, 16f1503, 16f15323.

In the 16f13115 manual, I found an interesting passage about Non Volatile Memory:
PFM can be protected in two ways: code protection and write protection. Code protection (Configuration bit CP) disables PFM read and write access through an external device programmer. Write protection prevents user software from writing to NVM areas tagged for protection by the WRTn Configuration bits. Code protection does not affect the self-write and erase functionality, whereas write protection does. Attempts to write a protected location will set the WRERR bit. Code protection and write protection can only be reset on a Bulk Erase performed by an external programmer. The Bulk Erase command is used to completely erase program memory. The Bulk Erase command can only be issued through an external programmer. There is no run time access for this command. If the device is code-protected and a Bulk Erase command for the configuration memory is issued; all other memory regions are also erased.

[Alberto Maccioni]

Bulk erase is what is issued, it completely erases the device.
Let's consider a 16F15355: it has the same programming specifications as a number of verified devices; this removes any uncertainty about firmware or algorithm.
Next is the LV adapter: you don't use it but I also tried without.
Hex file is also aligned.
What remains is pure hardware.
Did you use a pcb? Which components exactly?

[Dan Skareda]

I've updated my chip programming successes (sorry for the previous bad list). Today I tried them all again:
ok - 10f322 (DIP8), 12f509 (DIP8), 12f1572 (DIP8), 16f15355 (DIP28)
error - 16f15214 (DIP8), 16f13115 (SOIC8), 16f18014 (SOIC8), 16f18026 (SOIC14)

I tried using the LV adapter, but nothing changed.
So I thought, are you using exactly the same firmware (0.12.0) and opgui.exe (0.12.3) that you have on your web site?

I looked at your firmware and I couldn't find a place where the command value for bulk erase 0x18 is written to the programmed chip. Can you help me find it? Is it in OPcontrol.c here? But this sequence (0)100100(1) does not correspond either from the front or from the back to the code 0x18.

case BULK_ERASE_PROG: //Bulk erase program memory 001001 [4.5us]
 TXins(BULK_ERASE_PROG);
 INTCONbits.GIE=0;
 D1();
 CKpulseN();
 D0();
 CKpulseN();
 CKpulseN();
 D1();
 CKpulseN();
 D0();
 CKpulseN();
 CKpulseN();
 INTCONbits.GIE=1;
 breaks;

[Alberto Maccioni]

It's good that the 16f15355 has no problems; the others are not verified directly so in theory their algorithm could hide some issue.
I will check again the programming specifications.
Erase commands are not in firmware, because there are a lot of different variations.
Instedad a more universal instruction is used; for example for 16F18xxxx devices you can find these two lines in progp16.c:
bufferU[j++]=ICSP8_SHORT;
bufferU[j++]=BULK_ERASE_PROGRAM_MEM;
If you scroll all write functions you will find many variations.
Your PCB is different from mine; recently a user sent me his version and I found that the DCDC was self oscillating giving a high voltage.
Please verify that in your case VPP is always as expected; an oscilloscope is of course ideal.
As a safety measure you could place a 100pF capacitor between the base of Q1 and its emitter.

[Anonymous]

Dan Skareda: I ordered a new 16F13115 to verify that the current one is not defective (I will test it with an external VPP 8.7V). Can you please explain a few more questions to me first so that I can understand the communication process with the chip?
What do these terms mean in the log file created by opgui.exe when writing to the chip?
- what does PacketIO(......) mean
- what does bufferU=[......] mean
- what does bufferI=[......] mean
- "OK" at the end of the command lines is the chip's response that the command was received/executed, or the programmer's response that the data was received/executed correctly?
- what does T=31.12 ms (+1.12 ms) mean
According to the 16f13115 documentation, the maximum bulk erase memory time is 20ms. Do you mind that your timing is 15ms?
Thanks for the answers, I'm trying to get to know your code.

[Anonymous]

Erasing ... 
PacketIO(30,00)
bufferU=[
59 80 00 00 57 18 0A 0A 0A 0A 0A 59 80 F0 00 57 18 0A 0A 0A 0A 0A 04 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
bufferI=[
59 57 0A 0A 0A 0A 0A 59 57 0A 0A 0A 0A 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
59 ICSP8_LOAD 80 00 00 -> OK
57 ICSP8_SHORT 18 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
59 ICSP8_LOAD 80 F0 00 -> OK
57 ICSP8_SHORT 18 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
0A WAIT_T3 -> OK
04 FLUSH
T=31,12 ms (+1,12 ms)

[Anonymous]

Please help me explain BULK ERASE (0x18). According to the ICSP datasheet (for the 16f13115 circuit), 8 bits of the control word (0x18) should be sent, followed by 24 clock ticks (either with or without parameters). But I didn't find that in the OPCONTROL.C program in the firmware, only sending 0x18 via ICSP8_SHORT. Isn't it missing there?

case ICSP8_SHORT:
TXins(ICSP8_SHORT);
if(RXptr+1<number_of_bytes_read){
LOBYTE(d)=receive_buffer[++RXptr];
INTCONbits.GIE=0;
Ddir_bit=0; //Output
_asm
MOVLW 8
movwf i,0
ciclo_300:
RLCF d,1,0
BCF LATB,Dnum,0 //D0();
BTFSC STATUS,0,0 //Carry
 BSF LATB,Dnum,0 //D1();
 BSF LATB,CKnum,0 //CKpulseN();
 nope
 BCF LATB,CKnum,0
 decfsz i,1,0
 BRA ciclo_300
 _endasm
 D0();
 INTCONbits.GIE=1;
 }
 else{
 TXins(RX_ERR);
 receive_buffer[RXptr+1]=FLUSH;
 }
 breaks;

[Alberto Maccioni]

ICSP8_SHORT was designed to sent 8 bit commands