Verifying failed. PIC is 12F629. Programmer is RCD

[pasanlaksiri]

I found this fun project on the web.

3 channel IR remote control

Link > http://www.sixca.com/eng/articles/remote/index.html

There is two hex files for Tx and RX. I was able to program Rx hex file to PIC12F629. But when im trying to program Tx its giving me this error..

**broken link removed**

What will be the prob?

Thanks

Here r the HEX and ASM files

 

[jankop]

My by Code Protect problem?

Modify row:

__config _WDT_OFF & _XT_OSC & _CP_ON & _CPD_ON & _BODEN_OFF & _MCLRE_OFF & _PWRTE_ON

To:

__config _WDT_OFF & _XT_OSC & _CP_OFF & _CPD_OFF & _BODEN_OFF & _MCLRE_OFF & _PWRTE_ON

 

[mvs sarma]

Hi, It is perfect- as the program is with code protect. thus it will read as 0000 only. try to programm without verification or modify the asm file config bits _CP_OFF instad of _CP_ON

SIMILARLY _CPD_OFF
AFTER THAT SAVE THE FILE WITH ANOTHER NAME BUID THE HEX FILE WITH mplab AND THEREAFTER YOU TRY TO PROGRAMM. THIS PROBLEM WILL BE AVOIDED. ATTACHED SUCHA BUILD HEX FILE FOR READY USE.

 

[pasanlaksiri]

Hi, It is perfect- as the program is with code protect. thus it will read as 0000 only. try to programm without verification or modify the asm file config bits _CP_OFF instad of _CP_ON

SIMILARLY _CPD_OFF
AFTER THAT SAVE THE FILE WITH ANOTHER NAME BUID THE HEX FILE WITH mplab AND THEREAFTER YOU TRY TO PROGRAMM. THIS PROBLEM WILL BE AVOIDED. ATTACHED SUCHA BUILD HEX FILE FOR READY USE.

Nice. i'll try it

 

[pasanlaksiri]

Oh yaaaaa...... My problem is now solved

Thanks guys

 

[Nigel Goodwin]

Oh yaaaaa...... My problem is now solved

Pretty pointless adding code protection, the only time it might be useful is if you're releasing a commercial project, but even then you shouldn't set code protection while you're writing and debugging the code.

 

[donniedj]

Might be? Must be for commercial project. Code Protect has not prevented me from programming devices from within MPLAB IDE or PICKit Software using either a PICKit or an ICD2 clone. Their softwares verify the code but I suspect the verification is done DURING the programming. WinPIC800 and other third parties verify AFTER the programming. Code protection should not be an inhibitor to programming.

Perhaps Microchip programming software does not actually verify when Code Protection is set, unlikely. I attempted to get some info but the forum over there was just cleaned out. Anyhow, Code Protection should not burden the act of programming, and if there are softwares in existence that make it so, then that software ought to not exist. Or if Code Protection in itself burdens the act of programming, then it ought to be revised because Verification of code and Code Protection are a must.

 

[Nigel Goodwin]

Might be? Must be for commercial project. Code Protect has not prevented me from programming devices from within MPLAB IDE or PICKit Software using either a PICKit or an ICD2 clone. Their softwares verify the code but I suspect the verification is done DURING the programming. WinPIC800 and other third parties verify AFTER the programming. Code protection should not be an inhibitor to programming.

Perhaps Microchip programming software does not actually verify when Code Protection is set, unlikely. I attempted to get some info but the forum over there was just cleaned out. Anyhow, Code Protection should not burden the act of programming, and if there are softwares in existence that make it so, then that software ought to not exist. Or if Code Protection in itself burdens the act of programming, then it ought to be revised because Verification of code and Code Protection are a must.

As far as I'm aware, and certainly the way I've always implemented it, there are basically two methods of verification:

1) You verify every word after it's written, so a failure is found without having to write the entire device, WinPicProg always does this.

2) You verify all of the device after it's all written, in WinPicProg this option can be disabled in the menu.

As for code protection, you first write program memory and verify it, you then write data memory and verify it, last of all you write the configuration word(s) - once you've done that, with code protection set, you can't verify it. So you have either the option of disabling verification of the config word, or simply displaying a failure message - WinPicProg displays a failure message, because it's a sensible indication that you've set code protection ON.

But I'll repeat again - DON'T SET CODE PROTECTION UNLESS THERE'S A GOOD REASON - generally there's no need whatsoever, and it's completely pointless. You've perhaps all seen posts on here asking about breaking the protection on PIC's, claiming they have lost the source code for their program and need to be able to read the HEX file back out?. Personally I consider all such posts are lies, they are just trying to steal someone elses work - if it's NOT a lie, then they are just incredibly stupid, and if they have written it once, they can write it again!.

 

[Diver300]

Code protection doesn't stop the PIC being erased. It stops the code being read by others.

The microchip programmers do this:-
Erase
Program the code
Verify the code
Program the configuration bits, which stops the code being read if code protection is on

 

[Nigel Goodwin]

Code protection doesn't stop the PIC being erased.

Not 100% true - NEVER, EVER, under any circumstances, set code protection on a JW UV eraseable part - it means you can't ever erase the part again.

For EEPROM or FLASH parts erasing shouldn't be a problem, but if there's no reason, why do it?.

 

[mvs sarma]

Incidentally this is a case where the source code is published along with HEX file- there is no purpose of enabling code protection-- perhaps the code writer did it inadvertantly.

 

[pasanlaksiri]

Incidentally this is a case where the source code is published along with HEX file- there is no purpose of enabling code protection-- perhaps the code writer did it inadvertantly.

inadvertancy Oh no. I dont think so.

 

[mvs sarma]

inadvertancy Oh no. I dont think so.

if the code is written by you, i suggest in future the code locking could preferably be done after freezing the software and just while releasing the product-- so that this type of confusions could be prevented.

 

[pasanlaksiri]

if the code is written by you, i suggest in future the code locking could preferably be done after freezing the software and just while releasing the product-- so that this type of confusions could be prevented.

Nope, i didn't even try to write a coding yet .

 

[pasanlaksiri]

Woow... that 3 channel IR remote controler is workin nicely. I already connect it to my Room Lights

 

[mvs sarma]

Congrats Pasanlaksiri your work bench photos look impresive as posted elsewhere.

 

[pasanlaksiri]

Congrats Pasanlaksiri your work bench photos look impresive as posted elsewhere.

Thanks