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

[Alberto Maccioni]

Here a possible workaround: turn off and enter programming mode after erase.

[Dan Skareda]

Great! Programming 16f15214 and 16f13115 works with this version progP16.c! :-) Unfortunately, programming the 16f18014 and 16f18026 with this version does not work - after loading the programmed chip, all memory cells of the program memory, including the eeprom, are completely zeros (configuration word are also different).

[Alberto Maccioni]

Good, but still a workaround...
I wonder why bulk erase does not return the device to a ready state.
It would be interesting to ask Microchip; I'm not sure anybody would ever answer.
Unfortunately I don't have this device so I cannot experiment myself.
Now, regarding the next two devices, do you have a write log?
By the way, I also changed the overall function table.

[Dan Skareda]

I am attaching the protocol of writing to the 16f18026 chip. All zeros are written, although I compiled the project with the updated deviceRW.c.

[Alberto Maccioni]

Is it 0 in all memory or only where the hex file had data?
What do you see with a device read?
If you just erase it do you see zeros?

[Dan Skareda]

First, a few notes on the practical operation of opgui:

1) chips can only be erased after starting opgui - when I load the chip afterwards, I cannot clear the data area in opgui, I have to close opgui and reopen it - the "erase only" button is missing, even when the code is loaded in memory

2) after starting opgui, I do not see the preset (last used) chip - I have to click on the Device tab to check it. I would like the Data tab to display e.g. this:
Firmware version 0.12.0
Hardware ID: 0.0.4 (18F25K50)
Selected device: 16f18026

3) if I run only Erase (without writing data), it is confusing when the program writes that it is programming data:
...
Pin count: 14
Erasing ... completed
Writing code ... completed
Verifying code ... completed, 0 errors
Writing CONFIG area ...
completed, 0 errors

Now to the problem:

a) zeros are in the entire program memory 0000-3FFF including eeprom 00-FF, although I only erase the chip without programming
b) in the attachment the protocol after erasing the chip
c) I tried in the sequence:

else{ //bulk erase with bit field
bufferU[j++]=ICSP8_LOAD;
bufferU[j++]=BULK_ERASE_PROGRAM_MEM;
bufferU[j++]=0x00;
bufferU[j++]=programID?0x0F:0x0B;
bufferU[j++]=WAIT_T3; //3x7ms
bufferU[j++]=WAIT_T3;
bufferU[j++]=WAIT_T3;
}

change 0x0B back to 0x00, or extend the WAIT_T3 wait even more, but none of this solved the problem.

[Alberto Maccioni]

For the practical questions:
I did not provide an "erase" button on purpose; a significant part of users would always erase before programming, not knowing that erase is performed automatically or doing it "just to be sure"; this practice would cut the endurance without reason.
This way only "advanced" users do it when it is needed.
Chip preset is saved on exit, and you find it on the status bar upon start. Maybe you run the program from a different path and it doesn't find the status file.
Now, regarding the problem, I read again the programming specs and really don't find anything wrong; I'm out of ideas for today.
Here the latest source files.

[Dan Skareda]

Unfortunately, still all zeros (18014 and 18026). Is the Tdly time in bulk erase memory (in firmware) respected?

[Alberto Maccioni]

There were no changes in the algorithm, it is not expected to work any different.
The delay time is ~21ms; it is max 13ms according to programming specs.

[Anonymous]

I am just making sure I understand the code correctly. Speaking of Tterab, you have 3x WAIT_T3 in the program, but that is 9ms, right? (I tried 7x WAIT_T3 and it did not help)

else{ //bulk erase with bit field
bufferU[j++]=ICSP8_LOAD;
bufferU[j++]=BULK_ERASE_PROGRAM_MEM;
bufferU[j++]=0x00;
bufferU[j++]=programID?0x0F:0x0B;
bufferU[j++]=WAIT_T3; //3x7ms
bufferU[j++]=WAIT_T3;
bufferU[j++]=WAIT_T3;
}

But I meant Tdly, which is the clock pause between the instruction and the payload field. It should be 1us. For reading you have it created by a loop with NOP, but for writing it is missing.

Dan Skareda

[Alberto Maccioni]

In case of 180XX devices WAIT_T3 corresponds to 7ms.
If you refer to ICSP8_LOAD instruction, about 2us are required to fetch the data to be sent, so the Tdly limit (min 1us) is exceeded.

[Dan Skareda]

The sequence is now running 18 00 0B, then 3x WAIT and then FLUSH. Shouldn't it be 18 00 0B, then FLUSH and then 3x WAIT?

[Alberto Maccioni]

Instruction FLUSH means stop parsing the packet, so whatever comes after it is not executed.

[Dan Skareda]

So... I modified my LV PIC programmer (the project is here: https://github.com/jaromir-sukuba/a-p-prog) to be able to program 16F18026 (I use Vdd before Vpp mode, where Vpp=Vdd=5V) and I programmed (including bulk erase) the 16F18026 chip after a small firmware modification (see below the bulk_erase function) for the first time. Even the LED was blinking, although I did not modify the programming - so programming can be done by standard command 0x00/0x02. Here I will copy the most important parts of the firmware for A-P-PROG, the bulk_erase function:

void p16c_bulk_erase (void)
{
isp_send_8_msb(0x18);
_delay_us(5);
uint32_t data = 0b1011;
isp_send_24_msb(data);
_delay_ms(100);
}

void isp_send_24_msb (unsigned long data)
{
unsigned char i;
ISP_DAT_D_0
for (i=0;i<23;i++) 
{ 
if (data&0x400000) 
{ 
ISP_DAT_1 
} 
otherwise 
{ 
ISP_DAT_0 
} 
_delay_us(ISP_CLK_DELAY); 
ISP_CLK_1 
_delay_us(ISP_CLK_DELAY); 
data = data << 1; 
ISP_CLK_0 
} 
ISP_DAT_0 
_delay_us(ISP_CLK_DELAY); 
ISP_CLK_1 
_delay_us(ISP_CLK_DELAY); 
ISP_CLK_0
}

void isp_send_8_msb (unsigned char data)
{
unsigned char i;
ISP_DAT_D_0
for (i=0;i<8;i++)
{
if (data&0x80)
{
ISP_DAT_1
}
else
{
ISP_DAT_0
}
_delay_us(ISP_CLK_DELAY);
ISP_CLK_1
_delay_us(ISP_CLK_DELAY);
data = data << 1;
ISP_CLK_0
ISP_DAT_0
}
}

Try to verify that your program correctly enters the HV programming mode of the 16F18026. Bulk erase is implemented exactly according to the program specifications (it just has longer waiting times) and works in a-p-prog in LVP mode.

[Alberto Maccioni]

I would try different things if I had such device.
Anyways, it seems that it's only a matter of wait time after all.
According to your log the device enters programming mode; chip ID is correct.
You could try adding a delay, like:
msDelay(100);
(or even more) right before the "write code" section

[Dan Skareda]

Unfortunately, after the last regular Windows update yesterday, I will no longer be able to connect HID devices to the Linux WSL virtual machine. It seems that Windows has started to aggressively block HID devices and none of the many procedures lead to the possibility of connecting the HID type OP 1209:5432 to the WSL subsystem of Ubuntu. If you are willing to prepare an exe file for me, I can still try 16f18026 in windows. I will compile the program myself into a binary executable in WSL Linux, but the OP will not connect to WSL. Or let's change the VID:PID so that the device is identified as USB\Class_02 (CDC - Communication Device Class).

[Alberto Maccioni]

I use MSYS2, much less invasive than WSL; can you try that?
CDC is a different class, it works as a stream, like serial ports. OP transfers a whole packet, executes it, and sends back another packet.

[Dan Skareda]

Installing msys2 generates an error that I can't solve. I've already spent a lot of time on it and it's a shame to continue. So I'll try the next modifications in Raspberry OS. There, the opgui compilation works correctly. But it will take some time. When I have some results, I'll post them here.

[Dan Skareda]

I'm sorry, but your program is too complicated for me. I'm getting lost in it because it's very versatile and has many options. Could you simplify the whole progP16.c so that it only has erase bulk 16f18026 and nothing else? I tried adding delays in different places progP16.c, but nothing helped. The chip simply won't erase. So the problem must be somewhere else (firmware?), because log. txt always looks fine.
1) can you turn on LVP in opgui? We could verify that at least LVP (Vpp=5V) erases/programs correctly.
2) check out the website "tme.eu", that's where I buy all my PIC chips. They are reliable and carefully package smd circuits in low humidity mode, they are a really professional seller. You could buy 16f18026 from them.

[Alberto Maccioni]

Here a version with additional 200ms after bulk erase.
HVP or LVP does not make any difference; it already enters program mode, and the programming voltages are generated out of VDD anyways.

[Dan Skareda]

Eureka! :-) It wasn't the timing after erase, but the necessity to restart the chip before erase. Why it has to be done, I have no idea. Probably a bad previous command sequence, or a bad end of the command sequence.
I finally removed your timing 200ms after erase, it's not necessary.
So it works now! The LED is blinking. :-) I compile in Raspberry OS, there the compilation works correctly. However, the compiler reports a warning about ftime from the beginning (ftime is deprecated), do you know about that?
I have a total of 21 different types of PIC chips, so when you create a complete RC version, I will try all the chips.
Below is the code I added:

if(dim2>DCI[3]) dim2=DCI[3]; //limit EE to the real one
}
// ******************** erase memory ********************

if(TRUE){
j=0;
bufferU[j++]=EN_VPP_VCC; //enter program mode
bufferU[j++]=0x0;
bufferU[j++]=SET_CK_D; 
bufferU[j++]=0x0; 
bufferU[j++]=WAIT_T3; 
bufferU[j++]=EN_VPP_VCC; 
bufferU[j++]=4; //VPP 
bufferU[j++]=EN_VPP_VCC; 
bufferU[j++]=0x5; //VDD+VPP 
bufferU[j++]=FLUSH; 
for(;j<DIMBUF;j++) bufferU[j]=0x0; 
PacketIO(2); 
}

PrintMessage(strings[S_StartErase]); //"Erasing..." 
if(saveLog) fprintf(logfile,strings[S_sepLine]); 
if(saveLog) fprintf(logfile,"%s\n",strings[S_StartErase]); 
j = 0;

[Alberto Maccioni]

So now you are following the flowchart in the programming specs: enter prog mode -> bulk erase -> write etc.
The difference is that the program counter was previously still pointing to the DCI area @0x8200.
Try this file: I added an address load to 0 right before bulk erase.
If it works it means that bulk erase is not only sensible to the bitfield but needs PC to be in a specific address range.

[Dan Skareda]

Yes, with this progP16.c programming works correctly. :-)

[Alberto Maccioni]

Good, now everything is starting to make sense.
Let's go back to the previous problem with 16F152XX; it may be related to the address issue.
Can you try this modification?
It does not use the workaround but I think the latest code with PC to 0 could fix the issue.
Please also check the log file.

[Dan Skareda]

I tried to erase only the 16f15214 chip with your deviceRW.c. It did not erase. I attach the log that was generated during the erase. (next time, please send all the latest versions of the source data, so that there are no unnecessary errors due to different versions of the source files)

Below I copy the output when reading the erased chip:

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: 0x30E6
DevREV: 0x2008
16F15214
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 0020 0051 0042 0001 0043 0009 0020 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF
8110: 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 0401 0805 1005 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

Code memory:
0000: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0010: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

End (1.35 s)

The zeros written in the chip were created during my programming attempt. It seems to me that after the chip is not erased, zeros are written everywhere in the NWM where the code is supposed to be written. Only there and nowhere else. As if the subsequent write instruction after the erase was somehow disrupted.