Pic - K150 ICSP Programmer (HCDVBD0002)

[andrew]

If I re-load the hex file and set the oscal value again, I can verify the chip

the rom data passes but I get fuse error 0xFFF Good 0X0FEA Bad 0x0025

If I read back the chip, the code returns as in the hex file, with the chip's original OSCAL value, but the fuses show as follows: WDT:Encabled MCLRE:Disabled Oscillator:XT Code Protect:Enabled

Something is clearly wrong here as the fuse bits read back cannot be correct as it states the code protect fuse is set. This can't be the case as you wouldn't then be able to read the code back out of the device and verify it.

I have seen comments that Microbrn v150807 cannot read the fuse bits from 12c50xx devices. I'm currently trying to find where I saw this but if this is the case then it would explain the above contradiction. It would also then suggest that your devices may have actually programmed correctly.

Are you absolutely sure they aren't working?

[mikeyp]

Something is clearly wrong here as the fuse bits read back cannot be correct as it states the code protect fuse is set. This can't be the case as you wouldn't then be able to read the code back out of the device and verify it.

I have seen comments that Microbrn v150807 cannot read the fuse bits from 12c50xx devices. I'm currently trying to find where I saw this but if this is the case then it would explain the above contradiction.

Not sure on that count. If I read a blank chip, the fuses are read back as follows:
WDT:Enabled MCLRE:Enabled Oscillator:EX_RC Code Protect:Disabled
All fields except WDT are evidently being written, changed and read.

It would also then suggest that your devices may have actually programmed correctly.

Are you absolutely sure they aren't working?

I'm reasonably sure. It won't work unless it's configured to use the internal oscillator. I soldered one of mine into a PS One and got no change in behaviour, loading retail discs but not backups. Short of desoldering a known working chip (which was bought from someone else) from another console and swapping them, I can't be any more sure.

[andrew]

Not sure on that count. If I read a blank chip, the fuses are read back as follows:
WDT:Enabled MCLRE:Enabled Oscillator:EX_RC Code Protect:Disabled
All fields except WDT are evidently being written, changed and read.

Yeah this is part of my point, MicroBrn is giving conflicting information. The information read back from your blank chip seems sensible, however the moment it is programmed it looks to me that it is reporting fuse information that cannot be correct. If the code protect bit is set you should not be able to read the program back out again - which you've confirmed you can do. If the protect bit was really set it would just read out either all F's or all 0's. I've found the comments about Microbrn not reading fuse settings correctly. It talks about 12 bit PICs which includes 12c50xx parts:

KNOWN (UNFIXABLE) PROBLEMS WITH MICROBRN (Version: v200807)

- Does not always display the ID values in the 'Fuses' window for 12-bit core parts. MicroBrn may display an ID textbox for the 12-bit core Flash parts but it does not contain valid values that are either passed to the programmer or read back from the programmer. However, ID values embedded in the HEX file do seem to program correctly with the P18A firmware. (Previous firmware did not always support ID locations for 12-bit core PICs).

Given the above comments, and the fact that the code protect bit read back out of the device cannot be correct, then I am inclined to believe the fuse bit issue is simply due to the above bug. One thing it does suggest however is that the fuse bits won't program correctly unless they have been embedded into the hex file (this is an actual feature for PIC HEX files). Do you know if the HEX file you're using has the fuse bits setting included in it? Could you try the following:

Could you first load your HEX file into MicroBrn and then go to Options->Fuse Value and give me the value you see in there. Next, can you then read the code back out of the your programmed device and give me the value again. I'll see if I'll see if these values yield any useful information.

[mikeyp]

Given the above comments, and the fact that the code protect bit read back out of the device cannot be correct, then I am inclined to believe the fuse bit issue is simply due to the above bug. One thing it does suggest however is that the fuse bits won't program correctly unless they have been embedded into the hex file (this is an actual feature for PIC HEX files). Do you know if the HEX file you're using has the fuse bits setting included in it? Could you try the following:

Could you first load your HEX file into MicroBrn and then go to Options->Fuse Value and give me the value you see in there. Next, can you then read the code back out of the your programmed device and give me the value again. I'll see if I'll see if these values yield any useful information.

I'm not home until later so can't check the chip itself right now.
The fuse value reported by the dialogue box you instructed says:
Fuse 1 0FEA

If this is the same fuse as in the error from my first post, then I'm guessing the chip is reporting 0025.
(fuse error 0xFFF Good 0X0FEA Bad 0x0025)

I can provide the hex file if you like (or a link to where I obtained it) but not sure where you stand with this on this forum so let me know if you prefer me to post or pm it.

Also, don't know if it helps but the readme also says the following:

12c508a (not 12c508)
internal osc, all others off ! (except code protect if you want it)

Thanks again.

Edit: Confirmed tonight. The fuse values are as follows:
Blank chip: 0FFF
Hex file: 0FEA
Burned chip: 0025

[andrew]

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 can provide the hex file if you like (or a link to where I obtained it) but not sure where you stand with this on this forum so let me know if you prefer me to post or pm it.

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?

[mikeyp]

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.

[Louie_bee]

Hi, New to this.

have got the K150 running and setup as per the guide. Downloaded the recomended driver / software.

Running microbrn.exe and I can't see 12F635 in the chip select dropdown.

Looking in C:\GCB@Syn\K150\chipdata.cid I don't see 12F635

can I ask if Is this device supported by the K150? page 1 lists it as supported.

Many Thanks.

[Louie_bee]

By the way the above tec question is for a k150 purchase from hobby components

[andrew]

Running microbrn.exe and I can't see 12F635 in the chip select dropdown.

can I ask if Is this device supported by the K150? page 1 lists it as supported.

Really sorry about this. I can confirm that it's not supported by microbrn and it shouldn't be in the supported device list. I've just gone though the entire list of supported devices and updated it to make sure there are no other errors.

I've also taken a look at similar devices to the 12F635 with the hope of just copying the settings in the chipdata.cid file and modifying it for the 12F635 but I can't find any similar device that is supported by microbrn. My suspicion is that maybe the device was originally there and then removed because of issues.

If this means that your K150 is of no use to you without this support then please email sales [at] hobbycomponents.com and reference this forum post and we'll do our best to resolve your issue.

[Louie_bee]

Thanks for taking time to look at this Andrew. Yes it's all I needed the programmer for at the moment. I've emailed sales and hope to progress with the chip soon.

Regards,
Louie.