Page 1 of 1

Adding PIC16F887; some cfgmask Q's

PostPosted: 25, 2010 Feb Thu 7:27 pm
by Wook
Hello again,
Still fiddling with the MultiPic 5.2; never got around to swapping the 22uF caps back to 100uF - I think I'm going to just leave it as-is for now, as it seems to be working just fine. Swapping the 1k R3 out for a 10k resistor helped a great deal to keep the voltages stable.

The main reason I built the programmer was to program the PIC16F877 and PIC16F887 uC's. A couple of people had added definitions for PIC16F883 and PIC16F886, but they don't look quite right.

Anyway, I've been going through the datasheet and programming specifications for the PIC16F88x, and have updated much of it; just a few things I'm having problems with.

Here's where I am now; questionable lines are bolded:

info1= PIC16F887 uses a similar algorithm like 16F81x not 16F87xA!!!
info2= Added 2008-05-01 by Ivan D.
info3= Copied from PIC16F886; modified for 887 Steve W.
CodeMemType=1 ; 1=flash
CodeMemSize=8192 ; words, obtain from datasheet
DataEEPROMSize=256 ; bytes, obtain from datasheet
InternalRAMSize=368 ; Advisory information, will only be displayed
AddrConfigMem=0x2000 ; Almost always x2000
AddrConfigWord=0x2007 ; Configuration word start
AddrDataMem=0x2100 ; Convention on where this is stored in .HEX file
AddrOscCalib=0x2009 ; 8MHz Int Osc, POR, BOR, not only osc calibration
ConfigMemUsedLocs00_1F=0x03FF ; Bytes 2000-2009 are used, the remainder are "reserved"
ConfigMemUsedLocs20_3F=0x0000 ; unused
DeviceIdAddr=0x2006 ; 14 bit location, last 5 bits are for revisions
DeviceIdMask=0x3FE0 ; get from PDF PIC16F88x_flash_programming_41287C
;11 1111 1110 0000 bin for mask,
;10 0000 100x xxxx hex (actual value for PIC16F887)
DeviceIdValue=0x2061 ; get from PDF PIC16F88x_flash_programming_41287C
CanRead=0 ; Set to zero if using multi-word programming algorithm
EraseAlgo=ERASE_16F81x ; changed EraseAlgo according to notes in PIC16F883, was incorrect, changed to 16F81x Steve W. 2/23/2010
; examples. EraseAlgo=ERASE_16F62xA, ERASE_16F81x, ERASE_16F87xA, ERASE_16F87x, ERASE_12F6xx, PIC18F, PIC18F_OLD
VppVddSequence=Vpp_before_Vdd ; device supports all methods, but only this allows for all possible config words
Ti_Clock_us=5 ; typical value
Ti_Prog_us=10000 ; default value (10mS)
Ti_Erase_us=6000 ; default value=10mS, TERA = 6mS for PIC16F88x pg. 32
CmdLoadConfig=0 ; 0bxx0000 see table 3-1 pg 13
CmdLoadProg=2 ; 0bxx0010 see table 3-1 pg 13
CmdReadProg=4 ; 0bxx0100 see table 3-1 pg 13
CmdIncrAddr=6 ; 0bxx0110 see table 3-1 pg 13
CmdBeginProg=8 ; 0bx01000 or 8d for internal timing; 24d for ext timing ? Isn't the programmer supplying timing?
;CmdBeginProg=24 ; 0bx11000 or 24d for external timing; 8d for int timing ?
CmdEndProg=10 ; 0bx01010 10d
CmdLoadData=3 ; 0bxx0011 3d Serial command for "Load data for EEprom mem"
CmdReadData=5 ; 0bxx0101 5d Serial command for "Read data from EEprom mem"
CmdEraseProg=9 ; 0bxx1001 9d, internally timed
CmdEraseData=11 ; 0bxx1011 11d, internally timed
CmdEraseChip=-1 ; Not implemented in this uC
CmdBeginProgNoErase=-1 ; Not implemented in this uC
Cfgmask_unused=0x0000 ; All configuration bits used in word 1.
; 00 0000 0000 0000 configuration word 1 (pg 27, REGISTER 4-1)
; 11 1000 1111 1111 configuration word 2 (pg 28, REGISTER 4-2)
Cfgmask_unknown=0x0000 ; All configuration bits are known.
Cfgmask_cpbits=0x0040 ; Flash mem code prot bit 6 in word 1; 1=cp off, 0=000h-1fffh cp on
Cfgmask_cpd=0x0080 ; cpd data EE memory code prot bit 7; 1=cpd off, 0=cpd on
Cfgmask_pwrte=0x0010 ; pwrte bit 4; 1=PWRT disabled, 0=PWRT enabled
Cfgmask_inv_pwrte=0x0010; same as Cfgmask_pwrte
Cfgmask_wdte=0x0008 ; WDT bit 3: 0b1000
Cfgmask_oscillator=0x0007 ; bits 2 thru 0, 0b0111
Cfgmask_osc_rc=0x0007 ; 0b111
Cfgmask_osc_hs=0x0002 ; 0b010
Cfgmask_osc_xt=0x0001 ; 0b001
Cfgmask_osc_lp=0x0000 ; 0b000
Cfgmask_osc_extclk=0x0003 ; 0b011
Cfgmask_osc_intrc_clkout=0x0005 ; 0b101
Cfgmask_lvp=0x1000 ; 0b 01 0000 0000 0000
Cfgmask_boden=0x0300 ; 0b 00 0011 0000 0000
Cfgmask_mclre=0x0020 ; 0b 00 0000 0010 0000
Cfgmask_ddebug=0x2000 ; 0b 10 0000 0000 0000
Cfgmask_wrcode=0x0000 ; Write to code memory; this is in config word 2 bits 10-9 - how to access?
Cfgmask_bandgap=0x0000 ; Not implemented?
Cfgmask_ccpmx=0x0000 ; What is this parameter?
Cfgmask2_used_bits=0x0700 ; 0b 00 0111 0000 0000; bit 10=WRT1, 9=WRT0, 8-BOR4V ?
;Cfgmask2_wrcode=0x0600 ; Write to code memory; this is in config word 2 bits 10-9 - how to access?

Is there a formalized method for indicating bits used in configuration word 2? For example, WRT1, WRT0, and BOR4V is in config word 2, not word 1.

As I'd mentioned already, some of the information in both the PIC16F883 and PIC16F886 entries is not correct. Once I can get the PIC16F887 device definition debugged, the corrections for the other two devices will be nearly just a copy/paste.

In the PIC16F883 definition, these entries are not correct:
DeviceIdMask=0x01FF ; not sure about this...

I don't think these are correct either:

There are some goof-ups in the PIC16F886 definition too, but I want to make sure this new device definition is working before I start making changes to the other definitions.

Re: Adding PIC16F887; some cfgmask Q's

PostPosted: 25, 2010 Feb Thu 11:08 pm
by admin
I am not surprized that switching back to 100µF did not work with 500ms delay. If we suppose that 260 ms is the limit that just allows the 22µF to load in time, a first approximation of max capacitance with 500mS delay is 22 x 500 / 260 = 42µF. To work safely with 100µF, 2s would be probably necessary but that would make the programming significantly longer.

After checking the code, it appears that the Begin programming operation code is hard-coded when you select the 16F87xA programming algo. So the value of CmdBeginProg is ignored. The hard-coded value is 0x08 and is using the Ti_Prog_us as external programming delay.

For the Cfgmask_xxx parameters I think they are no longer used if you have a MPLAB dev file for your device. I think to remember that the MPLAB values overload the device.ini values for cfgmask. I suppose the MPLAB dev files replacement occured before the second config word exists. This is probably why it is not possible to specify that config bits are on the second config word through the device.ini file.

If I find enough time I have planned to change all the principle of device.ini file in the Version 2.0. There is a lot of clean up to do to give back some consistency to this patchwork of changes driven by the day to day PIC evolutions.