[16F18xxx & 152xx] OPGUI cannot write configuration registers1-5
An USB programmer for PIC, dsPIC, AVR, serial memories
Brought to you by:
albmcc
Menu
▾
▴
Data is exchanged in packets of 64 bytes, and once the outgoing packet is ready PacketIO(t) sends it and waits t ms before reading the response packet. Actually t is a hint; the function starts to wait a response even earlier, and can wait even more than t if nothing comes. The effective wait time is then printed a T=
bufferU and bufferI are the two packets.
In the log you see a parsing of the outgoing commands and their response; every command is acknowledged with an echo, so OK means that it was received
Sure, 14ms may not be enough.
You may want to read the source code guide
That Anonymous was me, just not logged in. :-) The more I study the program, the more differences I find from the programming specification. It seems that this family of circuits is really different from the others. But I don't understand PICs very well, so I'll leave that assessment to you. It would be great if you could fix it, the programmer is otherwise great.
Now that I look at it I see that the implementation lacks the payload.
At first glance it was similar to the picture in the 16F153XX programming spec.
Everything else is identical.
Sure, I can fix it adding another instruction and increasing the wait time.
Thank you. I will wait for the new version and then I will try programming all the PIC chips again. I also ordered 16f1503 and 16lf1705, so I have a lot of different PIC chips to try. Anyway, I really, really praise your project, because even the very expensive pickit3 can't program 16f13115, so your project is very useful.
Thank you for reporting the issue.
Probably I will post a release candidate this weekend in order to try the fixes.
I would like to give you practical advice for the next version - according to Microchip's recommendations, every code should contain configuration register settings. That's probably why you require it in your code. But as an ignorant person (and certainly not just me), if the user doesn't know this requirement, he may get confused and not understand what the programmer is requesting. I didn't understand from this message that the programmer explicitly requires register settings in the code. Can you clarify the message? For example
Last edit: Dan Skareda 2025-04-11
Try this, please
Great! It works. I tried 16f13115 and the chip was programmed and its RA2 led was blinking. :-) Later I will try all the other chips and post a report here.
16f18014 and 16f18026 - do not work. You will also need to add a payload field to 0x18. So the same modification as for the 13115 needs to be done for these circuits:
16f131xx series:
PIC16F13113, PIC16F13114, PIC16F13115, PIC16F13123, PIC16F13124, PIC16F13125, PIC16F13143, PIC16F13144, PIC16F13145
16f180xx series:
PIC16F18013, PIC16F18014, PIC16F18015, PIC16F18023, PIC16F18024, PIC16F18025, PIC16F18026, PIC16F18044, PIC16F18045, PIC16F18046, PIC16F18054, PIC16F18055,
PIC16F18056, PIC16F18074, PIC16F18075, PIC16F18076
16f181xx series:
PIC16F18114, PIC16F18115, PIC16F18124, PIC16F18125, PIC16F18126, PIC16F18144,
PIC16F18145, PIC16F18146, PIC16F18154, PIC16F18155, PIC16F18156, PIC16F18174,
PIC16F18175, PIC16F18176
16F15214 still doesn't work. In this case, it won't be the same problem as above, because this chip has bulk_erase without payload field. There will be some other error.
Last edit: Dan Skareda 2025-04-13
I checked the relevant programming specification briefly (for 16f15214):
1) LOAD (code 0x80) is 8 bits of code + 24 bits of address.
2) BULK_ERASE (0x18) according to the bulk erase table cannot have the address F000 in the PC (the address space for bulk erase ends with EFFF).
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
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
0A WAIT_T3 -> OK
04 FLUSH
When I programmed and checked the chip, I found that at the beginning of the address space from 0000 (the entry point of the program after reset) there are all zeros (as if this space was not erased), but from address 700 and higher the program is stored correctly and even so somehow works (the LED on RA2 is on and at the same time it goes out cyclically, which indicates that the vector at address 0000 is not programmed). So the error will be in erase PFM/NVM (instruction code 0x18) - as if the sequence of bytes creating the control code or data was scattered and therefore the memory area from address 0000 could not be erased. Because the following programming (with instruction code 0x02) will take place at higher addresses fine.
Here a new version with modifications for 16F18XXX .
Regarding 16F152XX I'm not convinced about your hypothesis; a first bulk erase is issued with the correct adress.
Anyways, now there is no extra erase without EEPROM .
No, it's the same.
Can you try just to erase it? Simply write after opgui starts without loading any hex file.
Then read the device; is it still partially written?
I tried to erase the 16f15214 chip according to your instructions and then read it. I don't know the addresses from the log, so I can't judge the success of the erase. Some data is read only at the end. I'm attaching the log. Why is the hex file saved after the reset so small? Is it because you don't put empty memory cells (0x3FFF) in it?
Last edit: Dan Skareda 2025-04-15
Looks correct, all locations contain 0x3FFF.
Hex files contain locations not empty.
Can you post the write log?
Here is a write to a completely empty (previously erased) chip. I verified the erase by reading before writing.
When I erase the code from address zero in the HEX file, the next address block in the sequence is programmed incorrectly - see attachment. So the first flashing of the data block after the erase function does not work correctly (or erase requires a longer time after the command), regardless of the address. Try to extremely increase the wait after erase 0x18 and preferably after 0xE0. Maybe it will help.
Indeed it could be a matter of delay after bulk erase command.
According to the programming manual 8.4ms should be enough; present delay is 14ms.
Try this version with additional 14ms.
Nothing, timing didn't help. I'm trying different variations of the hex file to get an idea of where the error is, but it programs differently.
For example this hex (line 0x80 is meaningless, it is only for programming purposes):
It programs like this:
(config probably programs well, because verify is ok)
Can't you think of something why the first line of data (here from address 0000 it is programmed twice and wrong?). I feel as if the program either cannot read the hex file, or the writing somehow overflows into programming zeros.
Another code variation:
This will program it like this:
(config probably programs well because verify is ok)
I'm attaching a hex file, can you try programming it into one of your chips, see if it's the same for you?
Last edit: Dan Skareda 2025-04-17
You can notice in the write log that data words are loaded with correct values, it's not a matter of errors reading a hex file.
32 words are written at the same time, and the first write after bulk erase is producing all 0.
Try with this version, just to exclude the delay theory; it has additional 250ms after bulk erase.
Unfortunately it's the same. Hex file:
was programmed like this:
Last edit: Dan Skareda 2025-04-18
ChatGPT studied the programmer files and found possible solutions, but the problem is that I have old programmer source codes, because you have probably already fixed this when troubleshooting 16f13115 programming. If you could not find the problem, please publish the source codes for the current version (which fixes 13115 programming) so that I can also help with finding the error.
Please verify this finding in 16f18xxx:
In this section of your code:
You're trying to skip 32-word blocks (rowN) that are completely empty (0x3FFF = erased flash). But here's what goes wrong:
Thus, when you later write this block:
It ends up writing all zeros because i is already pointing to the next (invalid) block, and memCODE_W[i + k] contains uninitialized data.)
Last edit: Dan Skareda 2025-04-19
I'm trying each version opgui.exe again and here is the result:
- version for 13115 - works 13115
- version for 18xxx - doesn't work 18014 or 18026 (doesn't works 13115)
- version for 15214 - doesn't work 15214 (doesn't works 13115)
Last edit: Dan Skareda 2025-04-19
ChatGPT? Hahaha, what a colossal waste of energy and silicon!
I'll answer this one, just to prove it doesn't get it.
The increment is not simply inside the loop, it's at the end of it, and it checks "valid" right after it is assigned the correct value.
Uninitialized memory, if it existed, would not be 0 but 0x3FFF.
In no way the following code can load zeros.
You see? Current AI are completely stupid, they don't know things, simply assume something is wrong because it is similar to one of the most common mistakes.
Sure, it sounds credible, and perfectly written; still, 100% BS.
Do yourself a favour: never believe an AI explanation for a bug.
By the way, you can see in the log file that data is loaded correctly (i.e. the correct command and payload is sent).
Also, this type of bug would show in all devices and would have been caught a long time ago.
The real problem could have two possible causes:
1) I did not read carefully or correctly interpret the programming specs (like with 13115)
2) Microchip did not write all details or missed something. This is unlikely but it happened a few times before.
In either case, ChatGPT would not be able to say anything useful; even if it managed to read the programming specs, it is too stupid to figure out anything.
Here the source code.
Thanks for the source code, the GCC compiler works for me, so I can compile the next versions myself. I'll try to figure something out.