| T O P I C R E V I E W |
| carlb |
Posted - 11/28/2010 : 20:25:27
I'm looking to programme Microchip PIC (SO28) processors using a GQ-4X USB programmer.
I am using the following processors in current designs:
8-bit: PIC18f26k20
16-bit: PIC24fj64gb002, dsPIC33fj128mc802
While the 16-bit parts appear not to be in the database at all, I do note that a *.dev file was provided for at least the 8-bit PIC18f26k20.
Unfortunately the only devices.txt entry for this chip is:
Name="PIC18F2620*DIP28",ID="XXXX",Class="PIC18F2XXX_4XXX",Category="MCU",MFG="Microchip",Package="DIP28",Platform="GQ-4X (>Re1.30)",PINVCC="ZIF32_PIN28";
with nothing for Name="PIC18F26K20*DIP28". I presume the DIP and SOIC are interchangeable (as the pinout is the same in this case) but the difference between 2620 and 26K20 is that the 26K20 is a low-voltage version of this part (it will run on 3.3V but is not usable on 5V)..
Is there a line which I should add to devices.txt to get the 26K20 to appear in the USBprg app? Is the device fully supported at this time?
I'd also be curious to know if there is any plan to include the 16-bit parts in a subsequent firmware revision?
|
| 11 L A T E S T R E P L I E S (Newest First) |
| carlb |
Posted - 12/22/2010 : 10:10:58
This is what I get if I do a "read" and then a "verify" (not a "write") on a blank PIC18F26K20 (DIP28):
Ready
H/W Re: GQ-4X Re-1.40
USB Driver Re.1.0
Software Re. 6.00
Checking new software on server...
DEVICE PIC18F26K20*DIP28
<<PIC18F26K20*DIP28>>
Load C:\source\ruler\pic\ruler.hex
c:\source\ruler\pic\ruler.hex.
This software is updated already.
ID check OK
Reading... Code
Elapsed time: 36.14 seconds.
Read completed.
ID check OK
Reading... Data
Elapsed time: 2.27 seconds.
Read completed.
ID check OK
Reading... User ID
Elapsed time: 0.07 seconds.
Read completed.
Reading... Configuration
Read completed.
ID check OK
Verifying... Code
OK
Elapsed time: 36.05 seconds.
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 4.41 seconds.
Indeed, I did click on "Verify" and the write CFG should not have happened. |
| ZLM |
Posted - 12/22/2010 : 01:00:32
I think you did not copy whole message log. If the verify in your Write process, then it is normal. If you click on "Verify", then the write CFG should not happen. |
| carlb |
Posted - 12/20/2010 : 12:56:27
I'm seeing the configuration bits zeroed (protecting the chip from further read attempts) even if I attempt a verify-without-write operation. This output is from a 'verify' operation, not a 'write':
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 7.18 seconds.
ID check OK
If this is a verify-only operation, why is it writing? |
| ZLM |
Posted - 12/18/2010 : 05:09:21
If the verify step in the write process, then it is normal. That because the configuration need to be written only after code and data been verified. It is standard procedure of Microchip.
However, if you only do the verification without write, then the CFG bit should not be written. If this is the case, then there is bug in software. |
| carlb |
Posted - 12/16/2010 : 13:23:53
This part looks weird:
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 7.18 seconds.
ID check OK
This is a "verify" operation only, yet it displays "Writing... Configuration" at one point and zeroes enough configuration bits to prevent any further read attempts (through code protection)?
I'd expect a "verify" should not be writing anything to the programmable memory bits. |
| carlb |
Posted - 12/13/2010 : 20:01:36
This is odd; I could programme a completely-blank (all 1's) image to the PIC18F26k20 and it would still show as code-protected. I proceed as follows:
- Erase
- Read (loads all-blank 1's into code/data/configuration bits)
- Write (writes the code/data and then gives "Configuration VerifyFailed")
- Verify (fails as all-0's even though the flash write was nominially OK - so protection bit activated in error)
Ready
H/W Re: GQ-4X Re-1.40
USB Driver Re.1.0
Software Re. 6.00
Checking new software on server...
DEVICE PIC18F26K20*DIP28
<<PIC18F26K20*DIP28>>
ID check OK
Erasing...
Elapsed time: 0.23 seconds.
Erase completed.
ID check OK
Reading... Code
Elapsed time: 35.84 seconds.
Read completed.
ID check OK
Reading... Data
Elapsed time: 2.26 seconds.
Read completed.
ID check OK
Reading... User ID
Elapsed time: 0.06 seconds.
Read completed.
Reading... Configuration
Read completed.
ID check OK
Writing... Code
Elapsed time: 53.49 seconds.
Device write completed OK
ID check OK
Writing... Data
Elapsed time: 8.38 seconds.
Device write completed OK
ID check OK
Writing... User ID
Elapsed time: 0.10 seconds.
Device write completed OK
ID check OK
Verifying... Code
OK
Elapsed time: 36.07 seconds.
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 7.18 seconds.
ID check OK
Verifying... Code
VerifyFailed, Address=0x000000, Device=0x00, Buffer=0xFF
VerifyFailed
Elapsed time: 3.37 seconds.
ID check OK
Even more strangely, if I start with a blank PIC18F26k20, attempting to "verify" the contents causes the configuration bits to be written, again locking me out from subsequent read or verify attempts using the 'code protect' bit:
Erasing...
Elapsed time: 0.23 seconds.
Erase completed.
ID check OK
Verifying... Code
OK
Elapsed time: 36.05 seconds.
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 8.82 seconds.
ID check OK
Verifying... Code
VerifyFailed, Address=0x000000, Device=0x00, Buffer=0xFF
VerifyFailed
Elapsed time: 2.07 seconds.
Something is being written to the configuration bits when it should not be there. I have all of the code protection bits 'disabled' (all 1's) and yet the device is being locked against all read attempts. It's likely that other configuration bits are incorrect, preventing proper operation of CPU clock or other functions in the targetted embedded application.
Another odd condition: I can start an operation (such as a 'verify'), click the 'cancel' button and then attempt to launch some other GQ-4X operation (such as a 'blank check' or 'ID') only to get "Progress Bar: Verifying... PIC18F26K20*DIP28" with no progress (stopped at zero). Restarting the app at this point won't help, if the app can be restarted at all. Closing the app, disconnecting the USB cable, then reconnecting and starting anew appears to be the only way to clear a failed 'cancel' attempt on a GQ-4X task. |
| ZLM |
Posted - 12/11/2010 : 10:09:20
The VerifyFailed on Code is due to the code been protected in your CFG WORD configuration. That is normal.
The Configuration VerifyFailed is the message bug. We will take look on this one. But the CFG bit should be been written correctly on chip.
Add your own devices into customdevices.txt file will avoid the overwrit by new software update.
|
| carlb |
Posted - 12/10/2010 : 13:00:59
The .hex file is still double the size of the corresponding .bin, even after upgrading to the new USBprg.exe application:
09/12/2010 18:46 110,898 ruler.hex
10/12/2010 15:25 44,246,653 ruler-gq4x.hex
where the first file is the output from Microchip's C18 and the second file is the same data (plus the option bits) as saved by USBprg.
I did have to re-insert the devices.txt entry as installing the new USBprg.exe appears to have overwritten it.
The microchip does appear to be powered from the GQ-4X correctly, although there are some additional pins being pulled up to 4.5V if one checks with a voltmeter; I'm not sure if this is by design or not.
I'm also still seeing the 'configuration bit' problems; the GQ-4X may be programming the microchips so that they're protected against both programme writes to flash and programmer read operations on flash or EEPROM as the programmed device reads back as all-zeroes:
Ready
H/W Re: GQ-4X Re-1.40
USB Driver Re.1.0
Software Re. 6.00
Checking new software on server...
This software is updated already.
DEVICE PIC18F26K20*DIP28
<<PIC18F26K20*DIP28>>
Load C:\source\ruler\pic\ruler.hex
c:\source\ruler\pic\ruler.hex.
ID check OK
Erasing...
Elapsed time: 0.23 seconds.
Erase completed.
ID check OK
Writing... Code
Elapsed time: 53.36 seconds.
Device write completed OK
ID check OK
Writing... Data
Elapsed time: 8.38 seconds.
Device write completed OK
ID check OK
Writing... User ID
Elapsed time: 0.10 seconds.
Device write completed OK
ID check OK
Verifying... Code
OK
Elapsed time: 36.06 seconds.
ID check OK
Verifying... Data
OK
Elapsed time: 2.47 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 6.11 seconds.
Selecting 'verify' then yields:
ID check OK
Verifying... Code
VerifyFailed, Address=0x000000, Device=0x00, Buffer=0xEF
VerifyFailed
Elapsed time: 2.86 seconds. |
| ZLM |
Posted - 12/09/2010 : 22:04:40
To avoid large size file, save the data into .hex file instead.
Use software Re6.0 for the fix on configuration problem. |
| carlb |
Posted - 12/09/2010 : 15:56:30
Looks like the device position should be PIC18F26K20 (DIP28) at the top of the 40-pin ZIF socket (so that pin 1-14 matches pin 1-14 on the socket), basically the opposite of that used for other devices (such as serial EEPROM) on the GQ-4X or other programmers.
I'm now able to programme the code segment but am having problems with the PIC18 configuration bits. I'm also finding that any attempt to save data read from the PIC18 to a .bin or .hex file creates a huge multi-megabyte output (as if this were an 0xF00800 byte device and not a tiny 64K-flash PIC18); this causes the app to sit at "Progress Bar: Reading" the next time USBprg.exe is run, as the attempt to preload this huge file on app startup causes USBprg to go into pretty much a "this application is not responding to Windows..." state.
The output I'm seeing for the PIC18F26K20 is currently:
Ready
H/W Re: GQ-4X Re-1.40
USB Driver Re.1.0
Software Re. 5.03B
DEVICE PIC18F26K20*DIP28
<<PIC18F26K20*DIP28>>
Load C:\source\ruler\pic\ruler.hex
c:\source\ruler\pic\ruler.hex.
Erasing...
Elapsed time: 0.23 seconds.
Erase completed.
Erasing...
Elapsed time: 0.23 seconds.
Erase completed.
ID check OK
Writing... Code
Elapsed time: 53.58 seconds.
Device write completed OK
ID check OK
Writing... Data
Elapsed time: 8.38 seconds.
Device write completed OK
ID check OK
Writing... User ID
Elapsed time: 0.10 seconds.
Device write completed OK
ID check OK
Verifying... Code
OK
Elapsed time: 36.12 seconds.
ID check OK
Verifying... Data
OK
Elapsed time: 2.48 seconds.
ID check OK
Verifying... User ID
OK
Writing... Configuration
Write Completed
Verifying... Configuration
Configuration VerifyFailed
Elapsed time: 13.02 seconds.
|
| ZLM |
Posted - 12/01/2010 : 11:01:01
Try to add this line into devices.txt file:
Name="PIC18F26K20*DIP28",ID="XXXX",Class="PIC18F2XXX_4XXX",Category="MCU",MFG="Microchip",Package="DIP28",VPP="9V",VCC="3.6V",WVPP="9V",WVCC="3.6V",Platform="GQ-4X (>Re1.30)",PINVCC="ZIF32_PIN28";
Please let me know if this works.
|
|
|
