| View previous topic :: View next topic |
| Author |
Message |
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
| Accidental Code Protect |
 Posted: Tue Jun 04, 2013 11:01 am |
 |
|
16LF819
CCS PCM C Compiler, Version 4.141, 2020 04-Jun-13 11:51
| Code: | #include <16F819.h>
#device adc = 10
#use delay (internal = 8MHz)
#fuses NOWDT,NOPUT,INTRC_IO,NOMCLR,NOBROWNOUT,NOLVP,NOCPD,NOWRT,NODEBUG,NOPROTECT
void main(void)
{
set_tris_b(0x00);
output_high(PIN_A1);
} |
When I burn this code I get a "Verification of Configuration Failed" warning. And then then my PICkit2 doesn't want to recognize it. It almost looks like it had code protection enabled. The PIC does seem to function. Pin_A1 goes high. It takes quite a process to erase the part then and get it back to a useable state. The LST file says:
| Code: | .................... set_tris_b(0x00);
000C: MOVLW 00
000D: MOVWF 06 |
According to the data sheet that's writing to PORTB instead of TRISB. Thoughts?
Just looking for someone to verify this. And I have never "rolled back" a compiler version but I've kept all my files. Could one of you offer advice on how to roll back and test to see if this is compiler version specific? Thank you. |
|
 |
z3ngew
Joined: 20 Apr 2013
Posts: 50
|
|
| Posted: Tue Jun 04, 2013 11:26 am |
|
|
I see you are using the noprotect fuse, so the code is not protected.
make sure you are selecting the correct type of device while burning the code to your device.
EDITED*
Good Luck,
z3ngew
Last edited by z3ngew on Tue Jun 04, 2013 2:27 pm; edited 3 times in total |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19366
|
|
| Posted: Tue Jun 04, 2013 11:29 am |
|
|
You need to look at the instructions 'in front' of this line.
Both TRISB, and PORTB are at the same direct address (6), but the bank select bits need to be set to '1' to address the latter (so it talks to the 'full' address 0x86). If the BSR is already set to '1' the compiler won't waste time reselecting it, but will just talk to address 6. I'd say you will find the BSR being loaded with '1' a few lines earlier. 
The bank select bits on this chip are Status:5, and Status:6.
This is 3.5 (in all banks), and 3.6.
In your code 3.5 is set seven lines earlier.
The compiler is correctly talking to the TRIS register.
Are you sure you have your programmer set to read the fuses from the source file?. If this option is 'off' then the fuses will probably default to protection on.
Best Wishes |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19366
|
|
| Posted: Tue Jun 04, 2013 11:31 am |
|
|
| z3ngew wrote: | I see you are using the noprotect fuse, so the code is not protected.
make sure you are selecting the correct type of device while burning the code to your device.
I see you are using 8Mhz crystal maybe you should use HS fuse
Good Luck,
z3ngew |
No. He is using the internal 8MHz RC oscillator. INTRC_IO, not HS.
He is saying that the chip behaved as if the protection had been turned on, _despite_ selecting NOPROTECT.
Best Wishes |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jun 04, 2013 12:06 pm |
|
|
This is really a Microchip question. Search their site for answers with this
Google search string:
| Quote: | | site:microchip.com "Verification of Configuration Failed" "pickit 2" |
|
|
|
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
|
| Posted: Tue Jun 04, 2013 1:39 pm |
|
|
Thanks Telmah
| Quote: | In your code 3.5 is set seven lines earlier.
The compiler is correctly talking to the TRIS register. |
I see that. Thank you. Also, the programmer is setting the config word according to the HEX.
PCM. Thanks for the tip. I'm cruising their site now.
I did another test.
| Code: | #include <16F819.h>
#device adc = 10
#use delay (internal = 8MHz)
//CHANGED CONFIG WORD TO INCLUDE MCLR
#fuses NOWDT,NOPUT,INTRC_IO,MCLR,NOBROWNOUT,NOLVP,NOCPD,NOWRT,NODEBUG,NOPROTECT
void main(void)
{
set_tris_b(0x00);
output_high(PIN_A1);
} |
This does not have my previously mentioned symptom. Thoughts? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jun 04, 2013 3:08 pm |
|
|
Yes, this looks like the standard old "internal oscillator with internal MCLR"
failire to program because of pecularities of certain Microchip programmers.
This problem has been around for quite a while. Refer to their site. |
|
|
stinky
Joined: 05 Mar 2012
Posts: 99
Location: Central Illinois
|
|
| Posted: Tue Jun 04, 2013 3:44 pm |
|
|
Thank you PCM. I'm glad to be aware of this peculiarity now.
EDIT:
Perhaps this is part of what happened:
From the Midrange-MCU Family Reference Manual , Section 28.9 found at:
http://ww1.microchip.com/downloads/en/devicedoc/33023a.pdf
| Quote: | If the MCLR pin does not rise fast enough, while the device’s voltage is in the valid operating
range, the internal Program Counter (PC) can increment. This means that the PC is no longer
pointing to the address that you expected to be at. The exact location depends on the number of
device clocks that occurred in the valid operating region of the device. |
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
