I read on the web that on a factory fresh PIC the configuration bits are all set to "1". True or false? And if false, how are they set from the factory?

 

That's mostly true but I wouldn't assume its always the case for every part. Many early PICs don't have the default specified at all, expecting that to be done at blast time. For a long and content life, I would recommend that your code always specify a full configuration that is qualified with the PIC you are using in case you ever change it e.g.

  ifdef __P184520
   CONFIG....
  else
   ERROR "Check config bits."
  endif

On a related note, early versions of MPASM defaulted unused config bits to various values. Later versions explicitly set unused bits to 1. Its been an issue when you try to validate a newly built .HEX after upgrading MPLAB. I've often found that a new .HEX is not the same as the old .HEX and the difference is in the setting of unused bits in the config reg.

Have fun.

 

John,

Thanks for the reply. Since I originally posted my question, I read that PIC programmers erase the devices before every programming, including the configuration bits. Thus, the configuration bits are all set to "1" before the PIC is programmed. Based on your comments above, I surmise that this is not always true, i.e., it's still better to set them all in every program rather than depend on the bits not explicitly programmed being set to "1" by default. Correct?

What piqued my curiousity was that in PBP3, the .info files for each PIC describe the defaults as prescribed by PBP3 during the programming process, and also describe all the configuration bit choices for that particular PIC. When I compared the two, I saw that PBP3 leaves some of the configuration bits out in its default programming.

I know that's a convoluted explanation, but it's the best I can do without writing a lot more. I have attached a .info file for the 12F683 as an example of what I mean. I changed the name of the file to a .txt so it will open with Notepad.

Thanks.

 

This doesn't answer your question, but what I do is always include a config.inc file in my .asm code that defines the processor, loads the .inc file for that processor, and sets the bits for the application. Changing config bits in the future is as simple as adding or removing comment marks ";" at the beginning of each line. Here's an example

;********************************
;** config.inc -- 18F84J90     **
;** Author: joeyd999           **
;** Derived from p18f84j90.inc **
;********************************

;define the processor and include the definitions

	processor	18f84j90
	include 	"p18f84j90.inc"

;configuration bit settings:

;   Background Debugger Enable bit (define ICD to enable):

#ifdef ICD
	config	DEBUG = ON           ;Background debugger enabled; RB6 and RB7 are dedicated to In-Circuit Debug
#else
	config	DEBUG = OFF          ;Background debugger disabled; RB6 and RB7 configured as general purpose I/O pins
#endif

;   Extended Instruction Set Enable bit:
	config	XINST = OFF          ;Instruction set extension and Indexed Addressing mode disabled (Legacy mode)
;	config	XINST = ON           ;Instruction set extension and Indexed Addressing mode enabled
;
;   Stack Overflow/Underflow Reset Enable bit:
	config	STVREN = OFF         ;Reset on stack overflow/underflow disabled
;	config	STVREN = ON          ;Reset on stack overflow/underflow enabled
;
;   Watchdog Timer Enable bit:
	config	WDTEN = OFF          ;WDT disabled (control is placed on SWDTEN bit)
;	config	WDTEN = ON           ;WDT enabled

;   Code Protection bit (define ICD or NOCODEPROTECT to disable):

#ifdef ICD
	config	CP0 = OFF            ;Program memory is not code-protected
#else

#ifdef NOCODEPROTECT
	config	CP0 = OFF             ;Program memory is code-protected
else
	config	CP0 = ON            ;Program memory is not code-protected
#endif

#endif

;   Two-Speed Start-up (Internal/External Oscillator Switchover) Control bit:
	config	IESO = OFF           ;Two-Speed Start-up disabled
;	config	IESO = ON            ;Two-Speed Start-up enabled

;   Fail-Safe Clock Monitor Enable bit:
	config	FCMEN = OFF          ;Fail-Safe Clock Monitor disabled
;	config	FCMEN = ON           ;Fail-Safe Clock Monitor enabled

;   Default/Reset System Clock Select bit:
	config	FOSC2 = OFF          ;INTRC enabled as system clock when OSCCON<1:0> = 00
;	config	FOSC2 = ON           ;Clock selected by FOSC1:FOSC0 as system clock is enabled when OSCCON<1:0> = 00

;   Oscillator Selection bits:
	config	FOSC = HS            ;HS oscillator
;	config	FOSC = HSPLL         ;HS oscillator, PLL enabled and under software control
;	config	FOSC = EC            ;EC oscillator, CLKO function on OSC2
;	config	FOSC = ECPLL         ;EC oscillator, PLL enabled and under software control, CLK function on OSC2

;   Watchdog Timer Postscaler Select bits:
	config	WDTPS = 1            ;1:1
;	config	WDTPS = 2            ;1:2
;	config	WDTPS = 4            ;1:4
;	config	WDTPS = 8            ;1:8
;	config	WDTPS = 16           ;1:16
;	config	WDTPS = 32           ;1:32
;	config	WDTPS = 64           ;1:64
;	config	WDTPS = 128          ;1:128
;	config	WDTPS = 256          ;1:256
;	config	WDTPS = 512          ;1:512
;	config	WDTPS = 1024         ;1:1024
;	config	WDTPS = 2048         ;1:2048
;	config	WDTPS = 4096         ;1:4096
;	config	WDTPS = 8192         ;1:8192
;	config	WDTPS = 16384        ;1:16384
;	config	WDTPS = 32768        ;1:32768
;
;   ECCP2 MUX bit:
;	config	CCP2MX = ALTERNATE   ;ECCP2/P2A is multiplexed with RE7 in Microcontroller mode or with RB3 in Extended Microcontroller mode
	config	CCP2MX = DEFAULT     ;ECCP2/P2A is multiplexed with RC1

 

I didn't explain that as well as I should have..

I read that PIC programmers erase the devices before every programming, including the configuration bits. Thus, the configuration bits are all set to "1" before the PIC is programmed. Based on your comments above, I surmise that this is not always true, i.e., it's still better to set them all in every program rather than depend on the bits not explicitly programmed being set to "1" by default. Correct?

When the device is erased prior to programming all bits in ROM, including the configuration word, are '1'. The config word will thus set the PIC to whatever '1' means in for the particular thing it controls. For the 12F683 FOSC bits in the CONFIG register

111 = RC oscillator: CLKOUT function on GP4/OSC2/CLKOUT pin, RC on GP5/OSC1/CLKIN

means that if you don't specify a CONFIG word in some way, the PIC will use the RC oscillator etc. But you knew that..

There have been several ways to specify the CONFIG over the years. The original way was to use the _CONFIG directive which ANDed several values (declared in p12F683.h) with '0' in strategic points. In FOSC above, the value to AND for the XT oscillator (FOSC=001) would be B'11111111 11111001'. ANDing the values for the various fields yields the net value to blast into the CONFIG register and as you correctly surmised, the other bits are expected to be '1' from erasing.

Setting CONFIG this way is supported for legacy reasons but has been superseded by CONFIG field=value as shown in joeyd999's example. The reason is that as PICs get more complex, they will have many CONFIG registers which can be a pain to manage. The new CONFIG directive is more portable when moving to a similar PIC or sometimes even going to a later version of the same P/N which may have minor changes to what's in the CONFIG register to support enhancements to the part. Rather than generate a literal value with _CONFIG, use CONFIG field=value and let the assembler sort it out. Your code will also be easier to read.

When its all said and done, the CONFIG settings will be in your .HEX file to be blasted along with the code. Here is where our confusion was. The .HEX generated by MPASM has used different values for the UNUSED bits in the CONFIG records in the .HEX. They used to be 0 but now are 1. 1 is better. Its not unheard of that a user will take a .HEX for one PIC and blast another P/N (i.e. moving from a CMOS part to its direct flash replacement). Sometimes while the basic architecture is the same, the later PIC may have different features that are controlled by the CONFIG reg e.g. code protection capabilities etc. Setting unused CONFIG bits to 0 would cause any new features to be enabled by 'default', not always a good thing. So you were correct in your assumption that unspecified CONFIG bits should not cause a problem if you can live with the defaults. My problem with that is you are leaving yourself open to missing something important and causing yourself grief.

So, my personal rules for CONFIG are:
Examine every field and explicitly set it in code, even if setting it to the default condition.
Use the later CONFIG field=value construct to free your code from the particulars of the CONFIG register(s).
Qualify the config settings with the processor type as I showed above to force an assembly time error to remind you to recheck the CONFIG settings if you decide to change PICs.
Use assemble-time switches as required to automate any config changes necessitated by a debugger. For example, RealICE requires that the watchdog and code protection be disabled for debugging. My production code always uses both so I have a switch (if DEBUGGING ; or something like that) that disables them for debug then switches in a completely different CONFIG block to enable them when building for release.

Take a look at the Programming Specifications for your PIC. Written for those designing programming hardware, its also a great insight into the CONFIG hardware.

Finally, when moving from one version of MPASM to another I compare new and old .HEX files to be sure the two versions generate the same code. Back in the day, MPASM was rather arbitrary about how it handled things such as case sensitivity in macros, the order of include files etc. sometimes generating a faulty programming image with no warnings from the assembler. Its much better now (default CONFIG values notwithstanding) but old habits die hard, especially when the scars are still visible. That was how I found the different (and yes, mostly benign) differences in the unused CONFIG settings.

Have fun!

 

I always set explicitly the whole thing. No doubts aftwerwards

TITLE     "PWM EXPLORER 01"
  
  SUBTITLE  "Started    15.06.09"
  SUBTITLE  "Completed  18.06.09"
  SUBTITLE  "Author Agustiin Tomaas Ferrari Nicolay - Buenos Aires"
;------------------------------------------------------------------------------

;Default radix is DECimal!
;Power control PWM testing, oriented to obtain a DC voltage range.

;XTAL = 4 MHz - HSPLL enabled.
;On line delay routines updated to 16 MHz (4 * 4 MHZ)
;------------------------------------------------------------------------------
 
  Processor 18F4431
  LIST  B=4, C=80, MM=ON, R=DEC, ST=ON, T=OFF

  INCLUDE "P18F4431.INC"
;------------------------------------------------------------------------------

  CONFIG  OSC =HSPLL  ,FCMEN =OFF   ,IESO =OFF    ,PWRTEN =OFF    ,BOREN =OFF
  CONFIG  BORV =27    ,WDTEN =OFF   ,WINEN =OFF   ,WDPS =1        ,T1OSCMX =OFF
  CONFIG  HPOL =HIGH  ,LPOL =LOW    ,PWMPIN =OFF  ,MCLRE =ON      ,EXCLKMX =RC3
  CONFIG  PWM4MX =RB5 ,SSPMX =RC7   ,FLTAMX =RC1  ,STVREN =ON     ,LVP =OFF             
  CONFIG  DEBUG =OFF  ,CP0 =OFF     ,CP1 =OFF     ,CP2 =OFF       ,CP3 =OFF             
  CONFIG  CPB =OFF    ,CPD =OFF     ,WRT0 =OFF    ,WRT1 =OFF      ,WRT2 =OFF            
  CONFIG  WRT3 =OFF   ,WRTB =OFF    ,WRTC =ON     ,WRTD =OFF      ,EBTR0 =OFF           
  CONFIG  EBTR1 =OFF  ,EBTR2 =OFF   ,EBTR3 =OFF   ,EBTRB =OFF