Pic - K150 ICSP Programmer (HCDVBD0002)

[anancil]

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

[andrew]

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

viewtopic.php?p=2618#p2618

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.

[tjfs]

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.

Code: [Select all] [Expand/Collapse]

1. Windows Registry Editor Version 5.00
2.  
3. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall]
4.  
5. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions]
6. "DenyDeviceIDs"=dword:00000001
7. "DenyDeviceIDsRetroactive"=dword:00000000
8.  
9. [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceIDs]
10. "1"="USB\\VID_067B&PID_2303"

GeSHi © Codebox Plus Extension

[driverplease]

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.

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...

Thanks,

David

[KeithS]

I'm having problems with the Prolific driver. I downloaded the one from the top of this post for Windows 10, installed it and it worked OK - was there as COM4 on my PC. Programmed a PIC ok with it. But after shutting down the PC and restarting, the port in Device Manager->Ports is shown as 'PL2303HXA PHASED OUT SINCE 2012. PLEASE CONTACT YOUR SUPPLIER'.

Then the only way to get it to work again is to uninstall it, reinstall the driver and restart the PC.

Is there a better solution???

[KeithS]

Is there a better solution???

OK so I have found a better solution. On reboot, WIndows 10 tries ever so helpfully to check if any of your drivers need updating. And of course there is an updated driver for this USB device, but it's the later Prolific one which tells you your chip is unsupported i.e. the PL2323HXA phased out' message. Hence why uninstalling and reinstalling the driver works, at least temporarily.

The solution is to prevent Windows from updating the driver. There is a way of doing this, see https://www.ghacks.net/2017/06/03/stop- ... c-devices/

It requires the group policy editor on WIndows i.e. gpedit.msc.

[andrew]

Thanks for that. I've now added a link to the first post for anyone else having the same issue.

[Martin20]

can the pic18f6720 be programmed with the k150? i need to reflash a picstart plus pum

[andrew]

I'm afraid that device isn't supported. The K150 is quite an old programmer and only devices that are specifically listed in the first post of this thread will work with it and the microbrn software.

[rootorry]

Hi there,

I am developing a multi purpose NMRA compatible DCC chip that can do very many different things from running up to 8 Servos, Multiple Headed Traffic Lights (Road and rail) as well as a multitude of other things.

To support all of this I am needing to store a lot of configuration information in the EEPROM of the PIC 18f4550 (or 18f2550) chips but my programmer is 'mis-writing' the EEPROM contents. It seems to be treating the EEPROM memory as being 16 bits wide and not 8 bits so it is only writing every other byte:-

I've attached the XC8 C code that creates the EEPROM values and the HEX file output is correct as can be seen in the same file.

The program itself checks out as can be seen by the MPLAB simulation.

The MicroBrn software and firmware is all matched up and I have no problems with the ROM code it is just the EEPROM bit that I cannot get my head around.

It is not a HobbyComponents supplied K150, I admit, but hopefully any help understanding what is going on would be very welcome.