Fresh PicKit2 issues

I've got my new PBRro v2.60a and Mecanique IDE and sample 16F1872 devices all working and running the ubiquitous led blinker... but only if I program the device from the PicKit2 application program.

I can't get the PicKit2 to program the part, from within the IDE, to save my life, even after following all the suggestions in the thread below:

Code:

---

Connecting programmer to MicroCode Studio

---

...and after using the same PicKit2 with "another" popular basic compiler and IDE for a couple years now.

I even transcribed the path script from the "other" IDE to the Mecanique IDE to no avail.

The only indication that the PicKit2 is being invoked at all is two very brief flashes of a DOS window each programming attempt.

I'd really like to make use of the PicKit2 from within the IDE.

Can anyone offer any tips?

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.

Quote:

---

Originally Posted by 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.

---

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?

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.

Quote:

---

Originally Posted by 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.

---

Thanks D, I'll try that.

Quote:

---

Originally Posted by 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.

---

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.

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.

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

Pickit2 does not support 16F1827...

Ioannis

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.

I just updated only the devicelist and has both chips in the support list!

Sorry I did not checked earlier. My mistake.

Please see the attached file.

Ioannis

I am sorry to be a pain about this, but I am trying to make a decision about this and not sure I understand. Let me ask directly:

If I have my buddy buy a PK2, will he be able to reprogram a 16F1947 with a hex file I supply. Using free software such as MPLAB or MCS(not free though)?

Is the update you posted for MPLAB or MCS or something different?

All your buddy needs is the PICKIT2, the PICKIT2 software and the hex. The software is free from microchip. No MPLAB or MCS needed.

:):):) Thank you Dave, I will tell him to proceed with the order.