Help with WinPIC please

I followed the instructs given by Wolfgang Buescher & added the PIC16F1708 to WinPIC. When I programmed a 1708, WinPIC stated that the programming had failed. The message said "0x008005 read 0x002005 wanted 0x003FFF". But the HEX code was green rather than red, so I tested the PIC & it worked except that RB5 (defined as an input) did not work. So I re-opened WinPIC & looked at the Config memory tab (see the first attachment). It indicates that location 0x8005 is 0x3FFF. So why did the message claim it read 0x2005? I then opened devices.ini (see second attachment) but could not find anything regarding 0x8005. Wolfgang's instruction did not mention this issue as far as I could determine. I bought a PICKit3 some years ago but it eventually failed & destroyed a 12F675. So I bought another PK3 & it worked for while, but when I recently attempted to programme a 16F1708, it destroyed the PIC. So I don't wish to buy any more PK3. Any assistance will be appreciated.

ljcox said:

I bought a PICKit3 some years ago but it eventually failed & destroyed a 12F675. So I bought another PK3 & it worked for while, but when I recently attempted to programme a 16F1708, it destroyed the PIC. So I don't wish to buy any more PK3.

Click to expand...

Wow.... I have never had an issue with PK3 and I have three of them.. Two originals and a clone..

Clearly the winPic software is looking to the wrong location.... Maybe a typo on wolfgangs instructions.

Take a look at the config bits in your setup against 8007 / 8 do they match! 09E4 is internal osc MCLEr enabled everything else off..

RB5 has PPS and AN11 on it.... Make sure ANSELB is clear..

You're doing something VERY badly wrong if you're destroying PIC's (they are extremely hardly devices), and PK3's certainly don't destroy PIC's, and are probably the most popular programmer in use today.

Click to expand...

There seems little or point in using anything other than MPLAB(X) with a PK3/4 - or even a PK2 if you only want to use old devices.

As regards your 'problem' why are you even checking 0x8005?, or is that a bug in the programmer software?, it's a read-only location (holding revision ID) and presumably shouldn't be 0x3fff.

The 14-bit device ID word is located at 8006h and the
14-bit revision ID is located at 8005h.

Click to expand...

Ian Rogers said:

Wow.... I have never had an issue with PK3 and I have three of them.. Two originals and a clone..

Clearly the winPic software is looking to the wrong location.... Maybe a typo on wolfgangs instructions.

Take a look at the config bits in your setup against 8007 / 8 do they match! 09E4 is internal osc MCLEr enabled everything else off..

RB5 has PPS and AN11 on it.... Make sure ANSELB is clear..

Click to expand...

Thanks Ian. My PK3s were clones. I don't fully understand your comments re config bits. Do you mean to look at devices.ini? Is 09E4 in devices.ini? What is MCLEr?

Nigel Goodwin said:

There seems little or point in using anything other than MPLAB(X) with a PK3/4 - or even a PK2 if you only want to use old devices.

As regards your 'problem' why are you even checking 0x8005?, or is that a bug in the programmer software?, it's a read-only location (holding revision ID) and presumably shouldn't be 0x3fff.

Click to expand...

Thanks Nigel. I used the first PK3 several times successively until one day it destroyed a 12F675. The same with the second PK3 - it worked well initially & then destroyed a 16F1708. I don't believe I did anything wrong. I always carefully check that the cable between the PK3 & the programmer is correctly oriented before doing the programming.

I use MPLAB 8.92. I don't need MPLABX. WinPIC has always worked for me in the past, but it did not include the 16F1708 so I followed Wolfgang's instructions & included the 16F1708 in the devices.ini. I looked at 0x8005 because WinPIC gave me a message said "0x008005 read 0x002005 wanted 0x003FFF"

reminds me of another situational example of where i have hooked the jumper backwards and crossed vcc and ground.

although anytime i have had bad read/write bytes, if not due to a partial fried chip or programmer, has lead me to a loose/poor/partial connection on the clk data nodes, or even a floating ground

ljcox said:

Thanks Nigel. I used the first PK3 several times successively until one day it destroyed a 12F675. The same with the second PK3 - it worked well initially & then destroyed a 16F1708. I don't believe I did anything wrong.

Click to expand...

There are HUGE numbers of PK3/4's in use, and you're the only person claiming they blow PIC's - it's pretty sure that you did something seriously wrong, at least twice.

What do you mean by 'destroyed' anyway?.

I'm more than sure your winPic script isn't quite correct as the config bits are not incorrect BUT the ID is incorrect... I have never used anything accept the IPE or the IDE from Microchip... The IPE is simpler than winPIc so I really don't know why you would use such software...

I also think the only way to fry a chip with pickit3 is if MCLRE is in the wrong place..

Nigel Goodwin said:

There are HUGE numbers of PK3/4's in use, and you're the only person claiming they blow PIC's - it's pretty sure that you did something seriously wrong, at least twice.

What do you mean by 'destroyed' anyway?.

Click to expand...

Nigel, Inspired by your post, I decided to re-visit. The reason I thought the PIC was destroyed was because it has 7 i/o defined as inputs & when tested, it did not work & 5 of the input i/o were reading 5 Volt. So I foolishly jumped to the conclusion it was damaged. Yesterday, I put it in the programmer & used WinPIC to read the hex file. It read successively, but the hex was nothing like what it should have been! I have no idea why that happened. I programmed it originally using PK3 via MPLAB. So I used WinPIC & it worked correctly. So thanks for your post.

Ian Rogers said:

I'm more than sure your winPic script isn't quite correct as the config bits are not incorrect BUT the ID is incorrect... I have never used anything accept the IPE or the IDE from Microchip... The IPE is simpler than winPIc so I really don't know why you would use such software...

I also think the only way to fry a chip with pickit3 is if MCLRE is in the wrong place..

Click to expand...

Ian, Thanks for the comments. I have been using WinPIC for many years. As I understand it, you need MPLAB X to drive IPE. I downloaded MPLAB X some time ago & found I was at the bottom of the learning curve & did not want to spend the time to learn it since MPLAB 8.92 & WinPIC are quite adequate for my purposes. Unfortunately, I found that the 16F1708 was not in WinPIC & decided to add it but got into some difficulty hence I started this thread. However, as you can see in my post to Nigel, I have resolved the issue.

ljcox said:

As I understand it, you need MPLAB X to drive IPE.

Click to expand...

Not at all.. Stand alone program.. I think IDE X installs but you can use the IPE as you would winPic.

I also put off moving to MPLAB IDE X because its too buggy... I hate Harmony.. I have clung like billyo onto the peripheral libraries..

I use VSM from labcenter as my IDE so I hardly use Microchip tools..

However!! I had to bite the bullet as all the lastest programs written for our co. is on the microchip platform ( sucks I know ) So I had to move over!!

Thanks Ian for the info. However, I'm happy with WinPIC as I can now, after some advice, programme the 16F1708 with it. But I'll keep the IPE in mind in case I need it in the future.

I can easily understand why you don't want to use the behemoth that is MPLABX IPE.

If you want an updated version of the old Pickit standalone programming app that supports more recent devices,
take a look at Pickit- (that's "pickit minus")


Supports the PK2, PK3, and it's free.