Pic - K150 ICSP Programmer (HCDVBD0002)

Microchip PIC development boards and accessories
Posts: 1
Joined: Fri Dec 25, 2020 11:02 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by anancil » Fri Dec 25, 2020 11:04 pm

How can i download the driver? I really need it.

Site Admin
Posts: 1148
Joined: Sun Aug 05, 2012 4:15 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by andrew » Sat Dec 26, 2020 8:09 am

It's available in the first post of this forum thread:


For the driver there is a Windows XP/7 version and an unofficial Windows 8/10 version so you will need to make sure you download the correct version. Also in the first post you will find a link to download a zip file containing the microbrn programming software.

Note you will have to be logged in to download these files.
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

Posts: 1
Joined: Thu Jan 21, 2021 5:23 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by tjfs » Fri Jan 22, 2021 3:08 pm

Windows 8/10 may try to update your Prolific USB driver which will stop it working.

If so, put this into a .reg file then double click to add it to the registry.
  1. Windows Registry Editor Version 5.00
  3. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall]
  5. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions]
  6. "DenyDeviceIDs"=dword:00000001
  7. "DenyDeviceIDsRetroactive"=dword:00000000
  9. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs]
  10. "1"="USB\\VID_067B&PID_2303"

Posts: 1
Joined: Sat Feb 06, 2021 12:48 am

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by driverplease » Sat Feb 06, 2021 1:28 am

mikeyp wrote:
Wed Feb 21, 2018 12:06 pm
andrew wrote:Thanks for those values. It looks to me like the HEX file has the fuse settings included and is trying to set the internal RC oscillator, watchdog disabled, internal rest, and code protection off. Which is all sensible so I'm inclined to believe these settings are real and correct. They also agree with your quoted comment. However the settings read out of the chip are external crystal, watchdog enabled, code protection on and external reset pin. These a clearly wrong and although it could be that device has been programmed incorrectly, which the fact that the chip doesn't seem to work backing that up, as mentioned before if the code protect bit was set it wouldn't be possible to read the the ROM data back out of the device again. So I'm still more inclined to believe that the fuse bits are programmed correctly and are being reported incorrectly due to the previously mentioned know bug with MicroBrn and 12 bit devices.
I have obtained another programmer now so will try with that and let you know the result, both of reading the K150 programmed chips and of writing with the other programmer and reading back with the K150.
andrew wrote:Yes, it's a bit tricky in how I can help with this. Whilst I personally believe you should be able to modify hardware you own in any way you like, and that there are legitimate reasons for doing this (I.e. for backup purposes), any advise in fixing this issue could be used to commit copyright infringement. So I think it's best that we discuss this offline. PM is turned off on this forum due to spamming problems but I have your email address. Can I email you directly?
Yes, please do. For the purposes of this forum, this is more about what's going on with the chips than what I'm doing with them. Personally, I have an almost 4 year old who is starting to play games with me and I definitely don't want her playing with my original discs. Some of them are rather expensive.
Hi All,

I was experiencing the exact same issues described here with fuses being incorrect after a burn and the chip not working. This is on an old K149-BC bought from a different vendor years ago (the URL on the board is to a chinese site, however the drivers and microbrn etc are the same deal)

Anyway, I *knew* it could write working 12C508A chips because it always used to last time I was messing with this stuff maybe ten years ago.

In troubleshooting between chip burns, I changed two things at once and don't know what did it. But:

A) I stopped using the old version of the software with USB passthrough to an XP guest in Virtualbox, and instead grabbed the Windows 10 versions attached to the first post (hence the throwaway username...)

B) I increased the ProgramDelay to 70 in the chipdata.cid, after reading around that this was the magic number for some other people.

Went from fuse errors to success messages. The fuse errors are *not* benign or just a bug or something. I haven't had one that threw an error and worked. First one that didn't throw the error worked...



Post Reply