Fresh PicKit2 issues

[Darrel Taylor]

Did you mean ...

Installing the PICkit2 Command Line Interface
http://www.picbasic.co.uk/forum/content.php?r=104

What version of the PICkit software do you have ... 2.61?
And what version of PK2CMD 1.20?

They must match.
The parameters must be EXACT as well.

[J. Mark Wolf]

Did you mean ...

Installing the PICkit2 Command Line Interface
http://www.picbasic.co.uk/forum/content.php?r=104

What version of the PICkit software do you have ... 2.61?
And what version of PK2CMD 1.20?

They must match.
The parameters must be EXACT as well.

Yes, I followed those directions, with the exception that I dowloaded a newer device file that includes the 16F1827.

And yes, PicKit2 v2.61.00, Device file v1.62.03, OS Firmware v2.32.00.

Another thing I noticed earlier while sorting some config syntax issues, is that the DOS window flashed very briefly while only compiling (F9). Now it flashes briefly twice, perhaps once while compiling and once while attempting to program (F10).

Don't know if this is normal.

Could it be a path issue?

[delateurj]

I have the same combination.

Here is the command line I use (accessed by selecting edit in the comiler and programmer options dialog):

/PPIC$target-device$ /F$hex-filename$ /M -h9 /I

the /M basically tells it to totally reprogram the device including an erase at start

the -h9 causes the dos window to say open for nine seconds. 9 is the max value. You can change that to -hk and that will cause the window to not be closed until you hit a key. If you do that and don't close the window you'll get an error on next time (at least I did).

/I causes it to display device ID and silicon revision.

[J. Mark Wolf]

I have the same combination.

Here is the command line I use (accessed by selecting edit in the comiler and programmer options dialog):

/PPIC$target-device$ /F$hex-filename$ /M -h9 /I

the /M basically tells it to totally reprogram the device including an erase at start

the -h9 causes the dos window to say open for nine seconds. 9 is the max value. You can change that to -hk and that will cause the window to not be closed until you hit a key. If you do that and don't close the window you'll get an error on next time (at least I did).

/I causes it to display device ID and silicon revision.

Thanks D, I'll try that.

[J. Mark Wolf]

I have the same combination.

Here is the command line I use (accessed by selecting edit in the comiler and programmer options dialog):

/PPIC$target-device$ /F$hex-filename$ /M -h9 /I

the /M basically tells it to totally reprogram the device including an erase at start

the -h9 causes the dos window to say open for nine seconds. 9 is the max value. You can change that to -hk and that will cause the window to not be closed until you hit a key. If you do that and don't close the window you'll get an error on next time (at least I did).

/I causes it to display device ID and silicon revision.

No change.

I have no idea what is wrong.

The same setup that has been working on my "other" popular PIC compiler for a couple years is now suddenly "broken" as well.

Someone on another forum, with the same problem, suggested that there was a conflict with a Microsoft.net installation. I indeed recently installed Visual Basic. Will explore that avenue.

It would be nice if the damn DOS window would stay open long enough to see what may be printed in there.

[J. Mark Wolf]

I found the following exchanges on the Microchip forum from people having difficulties with PK2CMD.EXE:

>> You are missing MSVCR80.DLL. This is typically found in .NET upgraded systems.
>>
>> PK2CMD requires the following files:
>>
>> 1. HID.DLL
>> 2. SETUPAPI.DLL
>> 3. KERNEL32.DLL
>> 4. MSVCR80.DLL
>>
>> Bingo!
>>
>> That's the culpritt. To work you actually also need to have the following
>>file in the system path Microsoft.VC80.CRT.manifest (or at least I do).

I'll poke around on my computer this evening and see what I can learn.

[Ioannis]

It is been a while for this thread, but just noticed it.

Pickit2 does not support 16F1827...

Ioannis

[cncmachineguy]

Thanks Ioannis, Now that you brought this up, I have looked. And according to MPLAB, the 16F1947 isn't either. This is bad new for me as I was gonna have my buddy get 1 to update his cards as I made changes.

I find it rather strange, does this mean the ICSP has changes between chips? I could understand if the extra features didn't work, but as a programmer I would have assumed it would be ok.