| T O P I C R E V I E W |
| n/a |
Posted - 11/19/2010 : 09:13:38
I have purchased GQ-4X about six months ago, and I can read a PROM with it. I have not tried to program PICs before. Today I upgraded to GQ USB Driver 2.01 and GQUSBprg 6.00. My GQ-4X has firmware version 1.30.
I have a PIC16LF628 chip. If I select device type PIC16F628 and try to read it, I get all 3FFF's for the Code, all FF's for the Data and all 3FFF's for the User ID. The Message Log says "Read completed". If I try to program the chip, writing succeeds (Device write completed OK), but verify fails with "VerifyFailed, Address=0x000000, Device=0x3F, Buffer=0x28".
There is no device type PIC16LF628. If I select PIC16LF628A I get a dialog box "File open error: C:\...\PIC16LF628A.dev device file".
The software reports 07C0 (type PIC16F628 revision 0) as the device ID.
I have tried this with USB power and with external 9V power supply. My USB port is directly connected to my Acer 9301 laptop. I'm running Windows XP SP3.
|
| 8 L A T E S T R E P L I E S (Newest First) |
| ZLM |
Posted - 11/26/2010 : 11:02:26
It seems the compatibility problem. We will check it on this issue. |
| n/a |
Posted - 11/24/2010 : 01:50:01
I took an IC socket and cut off all leads except those five. Then I inserted my PIC16LF628 into this socket and inserted the socket into GQ-4X. I used the new device type PIC16LF628 (see above). Now I could read the old contents of the chip! And I could write new contents, except that I got again error "VerifyFailed, Address=0x000706, Device=0x2B, Buffer=0x3F". I guess this must be because verify compares the whole contents, not just the space occupied in my .HEX file??? The Address in the message is no longer zero. Anyway, when I took my chip off and re-inserted it, the Read function returned my new data instead of FFs! So this looks very good! |
| ZLM |
Posted - 11/23/2010 : 10:32:34
This test is used to identify the problem. If this way works, then the problem is related to the chip compatibility and it may be solved by un-used pin connection. And the programming algorithm should have no problem. |
| n/a |
Posted - 11/23/2010 : 10:07:56
It would take a while before I have made the circuit... Could you elaborate what is the purpose of this test? Why using ICSP could solve this?
By the way, the write phase seems to succeed. Is that because writing really works or because the software+programmer do not check the writing (until the verify phase)?
While I'm building the circuit, are there any other quick checks that I could perform?
|
| ZLM |
Posted - 11/23/2010 : 09:51:33
One thing you can try is to program the chip via ICSP connection. That means do not place the chip on the programmer, instead to use the wires from programmer ZIF corresponding pin to the chip ISCP pins. The ICSP connection needs 5 wires from programmer ZIF to chip VPP VDD VSS CLOCK DATA pins.
Image Insert:
14.11 KB
Edited on Nov-23-2010 |
| n/a |
Posted - 11/23/2010 : 02:06:12
I tested my GQ-4X with device "2564(TEST)". I could read its contents and the checksum was OK.
But what can I do with my PIC16LF628? Can I perform some tests or can I turn on debugging or tracing?
|
| n/a |
Posted - 11/21/2010 : 08:43:33
quote:
Originally posted by ZLM
07C0 is a correct ID for 16LF628.
Add following line into devices.txt and see if it makes difference:
Name="PIC16LF628",ID="2907C0",Class="PIC16F628A",Category="MCU",MFG="Microchip",ENDPRG_COMMAND="",BEGERASECHIP_COMMAND="8",DeviceFile="PIC16F628.dev";
I added the line, but it did not help. The new PIC16LF628 behaves in exactly the same way as PIC16F628 (see my first message).
|
| ZLM |
Posted - 11/19/2010 : 21:38:35
07C0 is a correct ID for 16LF628.
Add following line into devices.txt and see if it makes difference:
Name="PIC16LF628",ID="2907C0",Class="PIC16F628A",Category="MCU",MFG="Microchip",ENDPRG_COMMAND="",BEGERASECHIP_COMMAND="8",DeviceFile="PIC16F628.dev";
|
|
|
