Pic - K150 ICSP Programmer (HCDVBD0002)

Microchip PIC development boards and accessories
andrew
Site Admin
Posts: 785
Joined: Sun Aug 05, 2012 4:15 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by andrew » Mon Feb 19, 2018 11:05 am

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?
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

mikeyp
Posts: 4
Joined: Mon Feb 12, 2018 11:45 am

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by mikeyp » Mon Feb 19, 2018 5:38 pm

andrew wrote: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.
andrew wrote: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
Site Admin
Posts: 785
Joined: Sun Aug 05, 2012 4:15 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by andrew » Tue Feb 20, 2018 10:12 am

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.
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

mikeyp
Posts: 4
Joined: Mon Feb 12, 2018 11:45 am

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by mikeyp » Tue Feb 20, 2018 10:36 am

andrew wrote: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
Site Admin
Posts: 785
Joined: Sun Aug 05, 2012 4:15 pm

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by andrew » Wed Feb 21, 2018 11:34 am

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?
Comments made by this poster do not necessarily reflect the views of Hobby Components Ltd.

mikeyp
Posts: 4
Joined: Mon Feb 12, 2018 11:45 am

Re: Pic - K150 ICSP Programmer (HCDVBD0002)

Post by mikeyp » 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.

Post Reply