Open Programmer Activity
An USB programmer for PIC, dsPIC, AVR, serial memories
Brought to you by:
albmcc
Activity for Open Programmer
-
John Devires posted a comment on discussion Open Discussion
Also just found the latest release 0.12.4, which works 100% on Mint. Thank you Alberto.
-
I had a similar problem on Linux Mint 20.3. The icons for "Read Device, Write Device and Quit" was not visible, only blank "place holders" Your solution, works 100% Thank you.
-
I had the same problem on Linux Mint 20.3. Thank you for the solution, works 100% ;)
-
Just another confirm. Tested 16F1827 , all works 100% Thank you.
-
Alberto Maccioni committed [dd3e3a] on Opgui
V 0.12.4 May 2025:
-
Open Programmer released /README.0.12.4.txt
-
Version 0.12.4 of OP/OPGUI was released today. Changes: added 18F04-05-06-14-15-16Q20; fixed config write on 18FXXQ10; fixed erase and write on 16F131XX,16F152XX,16F171XX,16F18XXX
-
-
-
-
-
-
-
-
Anonymous posted a comment on discussion Open Discussion
Ah, that's great. Basic support is fine and blink works. :-) I'm happy. Thank you for your effort and work - the programmer will be very useful. Dan Skareda
-
For reasons I really cannot understand, the progression of config# and address is interrupted after config8 (0x300007); next is config10 (0x300008), 11 and 12. Another jump and you get config14 (0x300018) and finally config9 (0x300019). This is only on Q20 devices. Clearly I did not implement a custom counter, and probably never will. By the way, SAFSZ is not written unless also SAFLOCK is. So in your case everything seems fine and exactly as expected.
-
Dan Skareda modified a comment on discussion Open Discussion
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): 04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): 04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
I read hex file ( with CONFIG14 that I added: #pragma config SAFLOCK = OFF and with CONFIG9: #pragma config SAFSZ = 0x80): 04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FF8067 :00000001FF This is what was displayed in opgui: CONFIG: [0x300000] 0xEC [0x300001] 0xFF [0x300002] 0xFF [0x300003]...
-
catweasle modified a comment on discussion Open Discussion
Never used the command line version. I tried starting the GUI version from a cmd window. First I programmed a spare 18F2550 which went well. Then I simply loaded the 512k hex file for the disPIC33 and the app shut down. No message in the DOS window. Maybe a buffer/memory issue while handling these large hex files but I can not replicate that on the other laptop where I finally had the success. Both are very old Dell, the app crashes on an Inspiron and works on my Latitude. I mentioned above that...
-
Never used the command line version. I tried starting the GUI version from a cmd window. First I programmed a spare 18F2550 which went well. Then I simply loaded the 512k hex file for the disPIC33 and the app shut down. No message in the DOS window. Maybe a buffer/memory issue while handling these large hex files but I can not replicate that on the other laptop where I finally had success. Both are very old Dell, the app crashes on an Inspirion and works on my Latitude.
-
Never used the command line version. I tried starting the GUI version from a cmd window. First I programmed a spare 18F2550 which went well. Then I simply loaded the 512k hex file for the disPIC33 and the app shut down. No message in the DOS window. Maybe a buffer issue while handling these large hex files but I can not replicate that on the other laptop where I finally had success. Both are very old Dell, the app crashes on an Inspirion and works on my Latitude.
-
Application crash is very strange; I don't remember it ever doing so. I tried Win10 and Win11 on multiple hardware. Do you see anny error message when started from command line?
-
These sources should support Q20. Write of SAFZ and SAFLOCK is only attempted if they are not empty and if error count is zero.
-
...oops, I missed your other post further above about AVDD and AVSS and added those. The ICSP port pinout has been changed so I can use my PICkit3 40pin Textool adaptor board with it and that works fine. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and one of it's USB ports didn't detect your programmer but the others did) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502...
-
...oops, I missed your other post further above about AVDD and AVSS and added those. The ICSP port pinout has been changed so I can use my PICkit3 40pin Textool adaptor board with it and that works fine. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart...
-
...oops, I missed your other post further above about AVDD and AVSS and added those. The ICSP port pinout has been changed so I can use my PICkit3 Textool adaptor board with it and that works fine. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart...
-
...oops, I missed your other post further above about AVDD and AVSS and added those. The ICSP port pinout has been changed so I can use my PICkit3 Textool daughter board with it and that works fine. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart...
-
oops, I missed your other post further above about AVDD and AVSS and added those. The ICSP port pinout has been changed so I can use my PICkit3 Textool daughter board with it and that works fine. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart the...
-
oops, I missed your other post further above about AVDD and AVSS and added those. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart the app a few times until the correct device ID showed up. Thanks for your help :D
-
oops, I missed your other post further above about AVDD and AVSS and added those. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 although I did have to restart the app a few times until the correct device ID showed up. Thanks for your help :D
-
oops, I missed your other post further above about AVDD and AVSS and added those. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 Thanks for your help :D
-
oops, I missed your other post further above about AVDD and AVSS. I managed to fire up an even older Windows laptop (the one I was using is already 10 years old and has at least one faulty USB port) and now the application doesn't crash mid programming and finally it worked. Device ID 0x1785 and code verified an all 6 dsPIC33EP512MC502 Thanks for your help :D
-
Because that is where I get the signals from and didn't realise it was an isolated connector. I thought conn43 is connected to conn5 ICSP which I indicated on my diagram. I got confused because you have D and CK labeled on conn43 and the 33x socket but I didn't see the D and CK on the left where the diodes are, which I thought were for other chips when I saw the D_5V and CL_5V labels. Your schematics have no wire connections drawn and I missed that. I am 70 y/o and my eyesight sucks. In any case...
-
Because that is where I get the signals from and didn't realise it was an isolated connector. I thought conn43 is connected to conn5 ICSP which I indicated on my diagram. I got confused because you have D and CK labeled on conn43 and the 33x socket but I didn't see the D and CK on the left where the diodes are, which I thought were for other chips when I saw the D_5V and CL_5V labels. Your schematics have no wire connections drawn and I missed that. I am 70 y/o and my eyesight sucks. In any case...
-
Because that is where I get the signals from and didn't realise it was an isolated connector. I thought conn43 is connected to conn5 ICSP which I indicated on my diagram. I got confused because you have D and CK labeled on conn43 and the 33x socket but I didn't see the D and CK on the left where the diodes are, which I thought were for other chips. Your schematics have no wire connections drawn and I missed that. In any case I have additionally to the resistors clamped D and CK but nothing changes....
-
You should connect AVDD and AVSS as well. In you drawing, the ICSP connector follows a different pinout; make sure to route the correct signals.
-
I'm not sure why you want to connect CONN43 to CONN5 or CONN4. Its function is to provide ICSP signals to a target requiring 3.3V signals. CONN5 does the same for 5V targets. CONN4, as you write, can be used to update the on-board firmware by connecting to another programmer; during this procedure you're supposed to unplug from USB.
-
SAFLOCK: Storage Area Flash (SAF) Lock Enable bit – 1 = OFF: SAF Lock disabled – 0 = ON: SAF Lock enabled, SAF areas are locked and the SAFSZ bits cannot be erased. Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = ON and with CONFIG9: #pragma config SAFSZ = 0xFF (If I upload this code to the device, I will never change SAFLOCK to OFF again) :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7...
-
SAFLOCK: Storage Area Flash (SAF) Lock Enable bit – 1 = OFF: SAF Lock disabled – 0 = ON: SAF Lock enabled, SAF areas are locked and the SAFSZ bits cannot be erased. Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = ON and with CONFIG9: #pragma config SAFSZ = 0xFF (If I upload this code to the device, I will never change SAFLOCK to OFF again) :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7...
-
I guess I don't understand you now. I'm using MPLAB X IDE. Here is the original version of the program for 18f06q20 that was flashed, without CONFIG14: :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFFF8 :00000001FF Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = OFF (edit: and...
-
I guess I don't understand you now. I'm using MPLAB X IDE. Here is the original version of the program for 18f06q20 that was flashed, without CONFIG14: :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFFF8 :00000001FF Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = OFF (edit: and...
-
SAFLOCK: Storage Area Flash (SAF) Lock Enable bit – 1 = OFF: SAF Lock disabled – 0 = ON: SAF Lock enabled, SAF areas are locked and the SAFSZ bits cannot be erased. Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = ON and with CONFIG9 that I added: #pragma config SAFSZ = 0xFF (If I upload this code to the device, I will never change SAFLOCK to OFF again) :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7...
-
SAFLOCK: Storage Area Flash (SAF) Lock Enable bit – 1 = OFF: SAF Lock disabled – 0 = ON: SAF Lock enabled, SAF areas are locked and the SAFSZ bits cannot be erased. Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = ON (If I upload this code to the device, I will never change SAFLOCK to OFF again) :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001...
-
SAFLOCK: Storage Area Flash (SAF) Lock Enable bit – 1 = OFF: SAF Lock disabled – 0 = ON: SAF Lock enabled, SAF areas are locked and the SAFSZ bits cannot be erased. Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = ON :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFF8 :02001800FEFFE9...
-
There seems to be an error on your schematic related to the PIC 24-30-33 daughter board which I forgot to to point out earlier. The ICSP port which you label ICSP-LV has the Vdd_L from the 3.3V regulator on pin 2. If that were to be plugged like that on your mainboard it would be shorted to VddU which is 5V when active. Then you have a port labeled ICSP-IN on the mainboard. It's function is unclear to me and I initially thought that might be to program the 18F2550 on board but now I am not sure as...
-
There seems to be an error on your schematic related the PIC 24-30-33 daughter board which I forgot to to point out earlier. The ICSP port which you label ICSP-LV has the Vdd_L from the 3.3V regulator on pin 2. If that were to be plugged like that on your mainboard it would be shorted to VddU which is 5V when active. Then you have a port labeled ICSP-IN on the mainboard. It's function is unclear to me and I initially thought that might be to program the 18F2550 on board but now I am not sure as it's...
-
It does show the data when I read from it and it is mostly FCFC00 as mentioned above so it is not that random. The programmer is built like your schematic with the 18F2550 and 12Mhz quartz but omitting the connections for the daughter boards. The layout of the ICSP port has been corrected to be compatible with the PICkit3. The programmer works fine with the PICkit3 daughter board (with the textool socket) and programmed a PIC16F630 flawlessly in HPV. 100Ω resisters are used for clk and data. The...
-
It does show the data when I read from it and it is mostly FCFC00 as mentioned above so it is not random. The programmer is built like your schematic with the 18F2550 and 12Mhz quartz but omitting the connections for the daughter boards. The layout of the ICSP port has been corrected to be compatible with the PICkit3. The programmer works fine with the PICkit3 daughter board (with the textool socket) and programmed a PIC16F630 flawlessly in HPV. 100Ω resisters are used for clk and data. The schematic...
-
It does show the data when I read from it and it is mostly FCFC00 as mentioned above so it is not random. The programmer is built like your schematic omitting the connections for the daughter boards. The layout of the ICSP port has been corrected to be compatible with the PICkit3. The programmer works fine with the PICkit3 daughter board (with the textool socket) and programmed a PIC16F630 flawlessly in HPV. 100Ω resisters are used for clk and data. The schematic of my disPIC33 daughter board, taken...
-
It does show the data when I read from it and it is mostly FCFC00 as mentioned above so it is not random. The programmer is built like your schematic omitting the connections for the daughter boards. The layout of the ICSP port has been corrected to be compatible with the PICkit3. The programmer works fine with the PICkit3 daughter board (with the textool socket) and programmed a PIC16F630 flawlessly in HPV. 100Ω resisters are used for clk and data. The schematic of my disPIC33 daughter board, taken...
-
It does show the data when I read from it and it is mostly FCFC00 as mentioned above so it is not random. The programmer is built like your schematic omitting the connections for the daughter boards. The layout of the ICSP port has been corrected to be compatible with the PICkit3. The programmer works fine with the PICkit3 daughter board (with the textool socket) and programmed a PIC16F630 flawlessly in HPV. 100Ω resisters are used for clk and data. The schematic of my disPIC33 daughter board, taken...
-
So config14 won't even be included as FF unless you declare it. What it SAFLOCK = ON ?
-
Device ID should be 1781; I don't think you wrote anything, it is just random disturbances on undriven IO lines. Can you draw the exact schematic you're using? There is no HV ICSP for this device.
-
The target IS using 3.3V which I mentioned above but maybe not clear enough. The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is it still writing, albeit gibberish? Edit: I just re-read that you said "Vpp is set to 5V" and that is what I am measuring, well actually 4.8V. So this must be LVP yet it doesn't work. I removed...
-
The target IS using 3.3V which I mentioned above but maybe not clear enough. The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is it still writing, albeit gibberish? Edit: I just re-read that you said "Vpp is set to 5V" and that is what I am measuring, well actually 4.8V. So this must be LVP yet it doesn't work. I removed...
-
The target IS using 3.3V which I mentioned above but maybe not clear enough. The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is it still writing, albeit gibberish? Edit: I just re-read that you said "Vpp is set to 5V" and that is what I am measuring. So this must be LVP yet it doesn't work. What am I missing here?
-
The target IS using 3.3V which I mentioned above but maybe not clear enough. The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is it still writing, albeit gibberish?
-
The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is it still writing, albeit gibberish?
-
The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps including the 10µF Vcap in ceramic and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is still writing, albeit gibberish?
-
The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts. If it is not entering programming mode, why is still writing, albeit gibberish?
-
The dsPIC33 is just on a naked board with the 3.3V regulator, usual caps and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts.
-
...just want to add the dsPIC33 is just on a naked board with the regulator, usual caps and the MCLR resistor to Vdd which Vpp is connected to. There are no shorts.
-
I guess I don't understand you now. I'm using MPLAB X IDE. Here is the original version of the program for 18f06q20 that was flashed, without CONFIG14: :04000000FEEF7FF0A0 :101600000000600E00017A6F806B8F9604012A97AC :1016100095969576210E016E760EE82EFED7012E58 :10162000FCD700D009EF0BF0FEEF7FF0000101EFD7 :021630000BF0BD :04FFFC0016EF0BF001 :020000040030CA :07000000ECFFFFFFFFFFFF13 :03000800FFFFFFFF8 :00000001FF Here is the version with CONFIG14 that I added: #pragma config SAFLOCK = OFF :04000000FEEF7FF0A0...
-
I just want to verify how the compiler handles config14 in a hex file. I added support for the additional Program access Enable, although it will rarely be used (if at all), because, as you wrote, it makes the device unwritable. In the end this feature will probably gain a general device option, disabled by default.
-
The device is clearly not entering program mode, otherwise you would see the chip ID. When using ICSP you have to be careful about loads attached to VDD; ideally your board would isolate the target VDD when programming (this is recommended by Microchip as well). I'm not sure why you don't have the 3.3V regulator, the target is supposed to handle 3.3V max voltage. VPP is set at 5V and current limited by a 10k resistor (on the expansion board) so you should replicate this arrangement.
-
My program that made the LED blink is attached. According to the datasheet, config9 and config14 are one-way bits that can be set to 0 (after the "allow program access" sequence), but never to 1 again. Just basic device support (erase and program) without setting the safe bit would be enough. ;-) Switching SAFLOCK to 0 means that I will never clear config9 to 0xFF again if I change it somehow. Maybe you meant the SAFSZ register config9, which can be reset to 0xFF if SAFLOCK=1. I would prefer not...
-
My program that made the LED blink is attached. According to the datasheet, config9 and config14 are one-way bits that can be set to 0 (after the "allow program access" sequence), but never to 1 again. Just basic device support (erase and program) without setting the safe bit would be enough. ;-) Switching SAFLOCK to 0 means that I will never clear config9 to 0xFF again if I change it somehow. Maybe you meant the SAFSZ register config9, which can be reset to 0xFF if SAFLOCK=1. I would prefer not...
-
My program that made the LED blink is attached. According to the datasheet, config9 and config14 are one-way bits that can be set to 0 (after the "allow program access" sequence), but never to 1 again. Just basic device support (erase and program) without setting the safe bit would be enough. ;-) Switching SAFLOCK to 0 means that I will never clear config9 to 0xFF again if I change it somehow. Maybe you meant the SAFSZ register config9, which can be reset to 0xFF if SAFLOCK=1.
-
My program that made the LED blink is attached. According to the datasheet, config9 and config14 are one-way bits that can be set to 0 (after the "allow program access" sequence), but never to 1 again. Just basic device support (erase and program) without setting the safe bit would be enough. ;-) Switching SAFLOCK to 0 means that I will never clear config9 to 0xFF again if I change it somehow.
-
My program that blinked the LED is attached. According to the datasheet, config9 and config14 are in certain cases one-way bits that can be set to 0 (after the "program access enable" sequence), but can never be set to 1 again. Only basic device support (erase and programming) without setting the safe bit would be enough. ;-) Or describe to me exactly what I should try, but so that I can then continue to use the device... :-)
-
Not working :( I can select the dsPIC33EP512MC502 I skip the 3.3V check. I am only using the ICSP port which does not carry the 3.3V from regulator I am using. Write starts OK but then this: all configs 0xFF device ID 0x0000 unknown device Erasing ... completed writing code ... completed Error verifying : mostly reads FCFC00 instead of the data that should be written exceed maximum number of errors (200) Takes several minutes then write interrupted Read shows most cells containing FF00FC00 and takes...
-
For now, the program for 18F06Q20 I recorded and it worked.
-
I will try with full support, but first I need a few bits of info. When you compile for 18F06Q20 is CONFIG14 (SAFLOCK) specified in the hex file? I guess it depends from what you write in the source. Can you provide two files with and without SAFLOCK bit set?
-
1) Both 16F171xx devices can be programmed fine with your latest modification. 2) I tried 18F06Q20 with device option 18F06Q40 and programming (and subsequent reading) went without errors and the led blinked. The programmer only reported unknown device. 3) As for 16LF1705, programming is fine. I found a short circuit on my breadboard with smd device. After removing the short circuit, everything is fine. 4) list of models verified by users - great idea - how about marking devices verified by users...
-
1) Both 16F171xx devices can be programmed fine with your latest modification. :-) 2) I tried 18F06Q20 with device option 18F06Q40 and programming (and subsequent reading) went without errors and the LED blinked. The programmer only reported unknown device. :-) 3) So that leaves 16LF1705. Even just reading the circuit returns signature 0000. I am attaching my LV board, I did not find any hardware error. 4) list of models verified by users - great idea :-)
-
1) Both 16F171xx devices can be programmed fine with your latest modification. :-) 2) I tried 18F06Q20 with device option 18F06Q40 and programming (and subsequent reading) went without errors and the LED blinked. The programmer only reported unknown device. :-) 3) So that leaves 16LF1705. Even just reading the circuit returns signature 0000. I am attaching my LV board, I did not find any hardware error.
-
1) Both 16F171xx circuits can be programmed fine with your latest modification. :-) 2) So that leaves 16LF1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment. 3) It would be good if you added at least basic support for 18F06Q20, for now without the ability to change SAFLOCK bits. I tried 18F06Q20 with the 18F06Q40 circuit set and the programming (and subsequent reading) went without errors. The programmer...
-
1) Both 16F171xx circuits can be programmed fine with your latest modification. :-) 2) So that leaves 16LF1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment. 3) I tried 18F06Q20 with the 18F06Q40 circuit set and the programming (and subsequent reading) went without errors. The programmer just reported an unknown device. :-) But I don't know if everything is OK yet, because my LED is not blinking - I probably...
-
1) Both 16F171xx circuits can be programmed fine with your latest modification. :-) 2) So that leaves 16LF1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment, are the two diodes regular diodes, or are they supposed to be zener diodes? 3) I tried 18F06Q20 with the 18F06Q40 circuit set and the programming (and subsequent reading) went without errors. The programmer just reported an unknown device. :-) But...
-
1) Both 16F171xx circuits can be programmed fine with your latest modification. :-) 2) So that leaves 16lf1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment, are the two diodes regular diodes, or are they supposed to be zener diodes? 3) I tried 16f06q20 with the 16f06q40 circuit set and the programming (and subsequent reading) went without errors. The programmer just reported an unknown device. :-) But...
-
1) Both 16F171xx circuits can be programmed fine with your latest modification. :-) 2) So that leaves 16lf1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment, are the two diodes regular diodes, or are they supposed to be zener diodes? 3) I tried to program 16f06q20 with the 16f06q40 circuit set and the programming (and subsequent reading) went without errors. The programmer just reported an unknown device....
-
Both 16F171xx circuits can be programmed fine with your latest modification. :-) So that leaves 16lf1705. I probably have a bad LV board, because even just reading the circuit returns the signature 0000. I'm attaching the board in the attachment, are the two diodes regular diodes, or are they supposed to be zener diodes?
-
Both 16F171xx circuits can be programmed fine with your latest modification. :-) So that leaves 16lf1705. I probably have a bad LV board, because even just reading the circuit returns a signature of 0000, I'll check it.
-
Both 16F171xx circuits can be programmed fine with your latest modification. :-) So that leaves 16lf1705. I probably have a bad LV board, because even just reading the circuit returns a signature of 0000, I'll check it.
-
Lots of points today! 18F06Q20: it has a flash lock feature so I did not want to add support without trying it myself; I may implement just the regular read/write. 16F1711X: it seems I made the same mistake as with 180xx, bulk erase with payload; easily fixable (attached file). 16LF1705: strange since I verified the 16F1703; I will try again my chip. DSPIC33CK256MP505: I have to check if the algorithm is similar to other dsPIC33. PIC32MX130F256B: once I tried a PIC32 but had some difficulties; then...
-
Lots of points today! 18F06Q20: it has a flash lock feature so I did not want to add support without trying it myself; I may implement just the regular read/write. 16F1711X: it seems I made the same mistake as with 180xx, bulk erase with payload; easily fixable. 16LF1705: strange since I verified the 16F1703; I will try again my chip. DSPIC33CK256MP505: I have to check if the algorithm is similar to other dsPIC33. PIC32MX130F256B: once I tried a PIC32 but had some difficulties; then realized that...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. I couldn't try it. 2) Programming the chip 16F17115 and 16F17126 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) 16LF1705 - I tried to program the blink project, the result was all zeros everywhere. Then I used the erase function, but there are still all zeros everywhere. 4) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 and 16F17126 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) 16LF1705 - I tried to program the blink project, the result was all zeros everywhere. Then I used the erase function, but there are still all zeros everywhere. 4) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support them in the future?...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 and 16F17126 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) 16LF1705 - I tried to program the blink project, the result was all zeros everywhere. Then I used the erase function, but there are still all zeros everywhere. 4) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support them in the future?...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 and 16F17126 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) 16LF1705 - erase programs all zeros everywhere 4) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support them in the future? Or we could try it together...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 and 16F17126 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support them in the future? Or we could try it together...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt 3) I have the opportunity to get DSPIC33CK256MP505 and PIC32MX130F256B. Will you support them in the future? Or we could try it together...
-
1) Please add the type of circuit 18F06Q20. It is not in the list. 2) Programming the chip 16F17115 does not work. No code is programmed. It seems that erase works correctly, but any programming does not. See. log.txt
-
You are right, they call the same write function with the same parameters.
-
The 33FJ128GP802 which I am also using for my project programs fine on my PICkit3 too. I just saw you have 24EP512GP202 written in bold in supported devices and it turns out that the dsPIC33EP512MC502 is confusingly in the same data sheet. I would have thought with it's DSP and ECAN ability it would deserve it's own data sheet but now I am somewhat hopeful that your solution might work. Coincidentally the project I am building that uses six of these tricky dsPIC33EP512MC502 also uses a 18LF25K50...
-
The largest dsPIC33 I verified was a 33FJ128GP802, 44KW or 128 KB. I don't have anything bigger currently.
1 >
