 |
 |
| View previous topic :: View next topic |
| Author |
Message |
tssir
Joined: 14 Feb 2016
Posts: 24
|
| write_program_memory and 18F27J53 |
 Posted: Tue Mar 21, 2017 12:06 pm |
 |
|
Hello,
I can't write flash program memory, by pic itself.
A simple example :
| Code: | #include <18F27J53.h>
#fuses NOWDT,NOSTVREN,NOXINST,NODEBUG,NOCPUDIV,NOPROTECT,INTRC,NOCLOCKOUT,NOFCMEN,NOIESO,NODSBOR,NODSWDT,NOIOL1WAY,NOWPFP,NOWPCFG,NOWPDIS
#DEVICE ADC=12, HIGH_INTS=TRUE
#use delay(clock=48MHz, USB_LOW)
// =========================================================================================================================================================
#define IO_SPI_SUPPLY_POWER PIN_C0
#define IO_3WIREBUS_DEBOUNCER PIN_C7
#define IO_BT_TX PIN_B0
#define IO_BT_SHUTDOWN PIN_B2
#define IO_BT_KEY PIN_B3
#define IO_3WIREBUS_OUTPUT PIN_B4
#define IO_CCL_TX PIN_B6
#USE fast_io(A)
#USE fast_io(B)
#USE fast_io(C)
// Set PIN_xx direction : 0==output, 1==input
// 76543210
#define TRIS_A (0b00001000)
#define TRIS_B (0b10100000)
#define TRIS_C (0b01000100)
#define PULLUP_B false
#define PULLUP_D false
#define PULLUP_E false
// =========================================================================================================================================================
#define STDPRG_DATA_EPPROM_ADDRESS_START ((__ADDRESS__)(getenv("FLASH_ERASE_SIZE")*1))
#define STDPRG_DATA_EPPROM_ADDRESS_END ((__ADDRESS__)(getenv("FLASH_ERASE_SIZE")*2-1))
void main(void)
{
byte buffer[getenv("FLASH_ERASE_SIZE")];
unsigned int16 bufferSize;
set_tris_a(TRIS_A);
set_tris_b(TRIS_B);
set_tris_c(TRIS_C);
port_b_pullups(PULLUP_B);
port_d_pullups(PULLUP_D);
port_e_pullups(PULLUP_E);
output_low(IO_SPI_SUPPLY_POWER);
output_float(IO_3WIREBUS_DEBOUNCER);
output_float(IO_BT_TX);
output_low(IO_BT_SHUTDOWN);
output_low(IO_BT_KEY);
output_float(IO_3WIREBUS_OUTPUT);
output_float(IO_CCL_TX);
for(bufferSize=0;bufferSize<64;bufferSize++)
{
buffer[bufferSize]=0x12;
}
write_program_memory(STDPRG_DATA_EPPROM_ADDRESS_START,buffer,bufferSize);
while(true);
}
#ROM STDPRG_DATA_EPPROM_ADDRESS_START={ 1,2,3,4}
#ORG STDPRG_DATA_EPPROM_ADDRESS_START+8,STDPRG_DATA_EPPROM_ADDRESS_END
{
}
|
Pic 18F27J53 datasheet :
| Quote: | "A read from program memory is executed on 1 byte at a time. A write to program memory is executed on blocks of 64 bytes at a time or 2 bytes at a time."
"Program memory is erased in blocks of 1024 bytes at a time."
"The program memory space is 16 bits wide, while the data RAM space is 8 bits wide."
"The programming block is 32 words or 64 bytes. Programming one word or 2 bytes at a time is also supported."
|
CCS documentation, about write_program_memory
| Quote: |
"Writes any number of bytes, will erase a block whenever the first (lowest) byte in a block is written to. If the first address is not the start of a block that block is not erased."
|
Compiler version : 5.043
| Code: |
.................... write_program_memory(STDPRG_DATA_EPPROM_ADDRESS_START,buffer,bufferSize);
000FC: CLRF FF8
000FE: MOVLW 04
00100: MOVWF FF7
00102: CLRF FF6
00104: CLRF FEA
00106: MOVLW 05
00108: MOVWF FE9
0010A: MOVFF 406,408
0010E: MOVFF 405,407
00112: MOVLB 0
00114: BRA 0026
.................... while(true);
00116: BRA 0116
.................... }
.................... #ROM STDPRG_DATA_EPPROM_ADDRESS_START={ 1,2,3,4}
.................... #ORG STDPRG_DATA_EPPROM_ADDRESS_START+8,STDPRG_DATA_EPPROM_ADDRESS_END
00118: SLEEP
.................... {
.................... }
Configuration Fuses:
Word 1: F78C NOWDT PLL2 PLLEN NOSTVREN NOXINST NODEBUG NOCPUDIV NOPROTECT
Word 2: FF12 INTRC_PLL_IO SOSC_DIG NOCLOCKOUT NOFCMEN NOIESO WDT32768
Word 3: F8F3 DSWDTOSC_INT RTCOSC_T1 NODSBOR NODSWDT DSWDT2147483648 NOIOL1WAY ADC12 MSSPMSK7
Word 4: FA80 NOWPFP NOWPCFG NOWPDIS WPEND LS48MHZ
ROM data:
000400: 01 00 02 00 03 00 04 00
|
I load and run the pic. Then, I read it's flash memory :
| Code: | :020000040000FA
:1000000047EF00F0FFFFFFFFF250036EF29EA68461
:100010000F01550EA76EAA0EA76EA6820000035010
:10002000F21200011200D08CF6503F0B006EC00E91
...
:10010000F76EF66AEA6A050EE96E06C408F405C4DD
:1001100007F4000188D7FFD70300FFFFFFFFFFFFB1
:10012000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDF
:10013000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCF
...
:1003E000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1D
:1003F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0D
:100400000100020003000400FFFFFFFFFFFFFFFFEA
:10041000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEC
:10042000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFDC
...
|
It seems that #ROM data is always on flash memory. write_program_memory have no effect !
I try erase_program_eeprom/write_program_eeprom with same result. I try many things all the day ...
Only erase_program_eeprom works and set memory block to FF (Only if it's used alone. An erase_program_eeprom after a read_program_memory not working).
Did you know any issue with write_program_memory on 18F47J53 family ?
Did I make a mistake ? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Mar 22, 2017 12:40 pm |
|
|
I ran your program in MPLAB vs. 8.92 simulator. I used two printf
statements to see your addresses:
| Quote: |
START = 00000400
END = 000007ff
|
Then I went to the "View / Program Memory" menu, and selected
the Opcode Hex tab. I scrolled down to address 0x400 and saw
that it worked. I then exported this address range to a file so
I could post it below. It shows 64 bytes are set to 0x12. (I removed
the ... dots at the end of each line for brevity).
| Code: |
003D0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
003E0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
003F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
00400 1212 1212 1212 1212 1212 1212 1212 1212
00410 1212 1212 1212 1212 1212 1212 1212 1212
00420 1212 1212 1212 1212 1212 1212 1212 1212
00430 1212 1212 1212 1212 1212 1212 1212 1212
00440 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
00450 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
00460 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
00470 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
|
So it's working in simulator. This was tested with vs. 5.068. |
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Wed Mar 22, 2017 2:33 pm |
|
|
Thank you very much for your test.
Then the source code seems ok.
I usualy manage application config flash memory with an ownmade library (based on write_program_memory). It works with some other pics, 16F1705 per exemple. Not with 18F47J53. But flash memory architecture is different.
I will try with an other 18F47J53 chip.
I will try same simple program with XC8 compiler.
I'll keep you informed. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Wed Mar 22, 2017 2:49 pm |
|
|
I felt compelled to install your version, 5.043 and test it. I got the same
results in the MPLAB vs. 8.92 simulator. It works in simulator.
Your read results appear to be a HEX file. You shouldn't have to do it
that way. You should be able to do a Read of the Program Memory in
MPLAB and then look at it using View / Program Memory / Opcode Hex tab
the same way I did.
Are you using MPLAB-X ? I don't use it.
If you get bad results again, I may have an 18F27J53 and could test it
in hardware. I'll have to check. |
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Thu Mar 23, 2017 8:05 am |
|
|
I use ccsc 5.043 and Mplab-X 3.55.
New test code :
| Code: | #include <18F27J53.h>
#fuses NOWDT,NOSTVREN,NOXINST,NODEBUG,NOCPUDIV,NOPROTECT,INTRC,NOCLOCKOUT,NOFCMEN,NOIESO,NODSBOR,NODSWDT,NOIOL1WAY,NOWPFP,NOWPCFG,NOWPDIS
#use delay(clock=48MHz, USB_FULL)
// =========================================================================================================================================================
#define IO_SPI_SUPPLY_POWER PIN_C0
#define IO_3WIREBUS_DEBOUNCER PIN_C7
#define IO_BT_TX PIN_B0
#define IO_BT_SHUTDOWN PIN_B2
#define IO_BT_KEY PIN_B3
#define IO_3WIREBUS_OUTPUT PIN_B4
#define IO_CCL_TX PIN_B6
#USE fast_io(A)
#USE fast_io(B)
#USE fast_io(C)
#define TRIS_A (0b00001000)
#define TRIS_B (0b10100000)
#define TRIS_C (0b01000100)
#define PULLUP_B false
#define PULLUP_D false
#define PULLUP_E false
// =========================================================================================================================================================
#define STDPRG_DATA_EPPROM_ADDRESS_START ((__ADDRESS__)(getenv("FLASH_ERASE_SIZE")*1))
#define STDPRG_DATA_EPPROM_ADDRESS_END ((__ADDRESS__)(getenv("FLASH_ERASE_SIZE")*2-1))
void main(void)
{
byte buffer[getenv("FLASH_ERASE_SIZE")];
unsigned int16 bufferSize;
set_tris_a(TRIS_A);
set_tris_b(TRIS_B);
set_tris_c(TRIS_C);
port_b_pullups(PULLUP_B);
port_d_pullups(PULLUP_D);
port_e_pullups(PULLUP_E);
output_low(IO_SPI_SUPPLY_POWER);
output_float(IO_3WIREBUS_DEBOUNCER);
output_float(IO_BT_TX);
output_low(IO_BT_SHUTDOWN);
output_low(IO_BT_KEY);
output_float(IO_3WIREBUS_OUTPUT);
output_float(IO_CCL_TX);
for(bufferSize=0;bufferSize<64;bufferSize++)
{
buffer[bufferSize]=0x12;
}
write_program_memory(STDPRG_DATA_EPPROM_ADDRESS_START,buffer,bufferSize);
read_program_memory(STDPRG_DATA_EPPROM_ADDRESS_START,buffer,bufferSize);
if(buffer[0]==0x12)
{
while(true) {output_toggle(IO_BT_KEY);delay_ms(100);} // Quick led flashing
}
else
{
while(true) {output_toggle(IO_BT_KEY);delay_ms(1000);} // Slow led flashing
}
}
#ROM STDPRG_DATA_EPPROM_ADDRESS_START={ 1,2,3,4}
#ORG STDPRG_DATA_EPPROM_ADDRESS_START+8,STDPRG_DATA_EPPROM_ADDRESS_END
{
}
|
Modifications :
- Remove USB_LOW option : Cause a false time base computation by ccsc (real time*4 with delay_ms, per example). Anyway, it changes nothing to the result.
- Reads flash memory after writing it, and check one value. Quick led flashing if value is correct. Slow flashing if false.
1) I try a brand new 18F27J53 chip. Same result : no flash memory modification. Slow led flashing = flash memory does not change.
I check my 18F27J53, by loading entire flash memory with PicKit3. It confirms the result.
2) I load the same .hex file on Mplab-X, to simulate it. As you, flash memory changed. It works ! Then binary code works on simulator, but not on real chip.
I am disapointed. I should consider the problem more widely. I probably do an error somewhere ...
I'll keep you informed. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
| Posted: Thu Mar 23, 2017 8:59 am |
|
|
Why are you specifying USB at all?. No sign of it in your code, and USB_LOW forces the oscillator to give 12Mhz, not 48...
This is a 'read the datasheet' one. You are telling the compiler two conflicting things.
The reason it doesn't complain, is that you are using it wrong. If you read the manual, it says that the USB options 'if used with the type=speed', will automatically setup the oscillator. Because you are instead specifying the 'clock=' format, this assumes _you_ know what you are doing, and are setting everything else right....
If you do intend to use USB, and select USB_HIGH, with the internal oscillator, you need to add 'ACT=USB' to the clock setup line. You can't actually run USB off the internal oscillator alone (not accurate enough), which is where 'ACT' (active clock tuning) comes in. It phase locks the i8nternal oscillator to the USB bus, when the bus is attached to give an accurate frequency.
So the correct syntax, is:
#use delay(internal=48MHz, USB_FULL, ACT=USB)
Your answer is almost certainly that MPLAB-X is not working right. I have yet to see a release of this that even gets close to fully operating.... |
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Thu Mar 23, 2017 9:14 am |
|
|
Thank you for informations.
You are true, USB is useless for my test. It's a bad copy from other project to get the FUSE and clock line. No impact on result.
I know that it is not the place to find Mplab-x friends ... |
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Fri Mar 31, 2017 1:51 pm |
|
|
I am still not able to write PIC18F program memory with CCS ...
After many, many, many tries. Neither with ASM or C.
MPLAB simulator is not reliable. Memory self programming works in every way with MPLAB, even not working case with real chip (in accordance with pic datasheet). I think that TBLWT does not have the real behavior in simulator.
But i have somes news about the first problem : unable to read before erase. If i call "read_program_memory" at least one time before "erase_program_eeprom", erase_program_eeprom have no effects. While the procedure of the datasheet shows that you MUST read, update data on ram, erase and then write.
This code not works :
| Code: |
#ASM
CLRF TBLPTRU ; MOVLW 0x04 ; MOVWF TBLPTRH ; CLRF TBLPTRL ; // Setup 0x400 memory address
MOVLW 4 ; // number of bytes in holding register (same result with 64)
MOVWF &writeBufferOffset // setup counter
label_READ_BYTE_TO_HREGS :
TBLRD*+
MOVF TABLAT, W
MOVWF buffer // rewrite on same address, i do not care about the value for this example
DECFSZ &writeBufferOffset,F // loop until buffers are empty
BRA label_WRITE_BYTE_TO_HREGS
#ENDASM
erase_program_eeprom(STDPRG_DATA_EPPROM_ADDRESS_START);
|
"erase_program_eeprom" have no effect. Memory keeps original values.
This code works :
| Code: |
#ASM
CLRF TBLPTRU ; MOVLW 0x04 ; MOVWF TBLPTRH ; CLRF TBLPTRL ; // Setup 0x400 memory address
MOVLW 4 ; // number of bytes in holding register
MOVWF &writeBufferOffset // setup counter, unnecessary but identical to previous example
TBLRD*+
MOVF TABLAT, W
MOVWF buffer // rewrite on same address, i do not care about the value for this example
DECFSZ &writeBufferOffset,F // loop until buffers are empty
TBLRD*+
MOVF TABLAT, W
MOVWF buffer // rewrite on same address, i do not care about the value for this example
DECFSZ &writeBufferOffset,F // loop until buffers are empty
TBLRD*+
MOVF TABLAT, W
MOVWF buffer // rewrite on same address, i do not care about the value for this example
DECFSZ &writeBufferOffset,F // loop until buffers are empty
TBLRD*+
MOVF TABLAT, W
MOVWF buffer // rewrite on same address, i do not care about the value for this example
DECFSZ &writeBufferOffset,F // loop until buffers are empty
#ENDASM
erase_program_eeprom(STDPRG_DATA_EPPROM_ADDRESS_START);
|
"erase_program_eeprom" works, and whole block memory is set to 0xFF.
The only difference, is an unconditional jump (BRA, or GOTO). I try to delay some lines with NOP, with no more success.
So, i am able to implement a by-pass solution. But i can't understand this behavior. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 31, 2017 9:58 pm |
|
|
I wrote a simple test program and it worked for me, in hardware.
I installed your CCS version, vs. 5.043. I'm running an 18F27J53 on a
Olimex Pic P28 board, Rev. D. I'm using MPLAB vs. 8.92 as the IDE.
I'm using TeraTerm as my serial terminal program. It displays the
following output when I run the program:
| Code: | Start
Bytes read from Flash memory address 0x400:
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
12 12 12 12 12 12 12 12
|
That's correct. Before I did this test, I was running CCS vs. 5.070
and I filled the flash memory with incrementing data, from 0x00 to 0x3F,
and it read that data and displayed correctly. So I know the flash had
different data than 0x12 at the start. Then I ran the program below
(compiled with vs. 5.043), and it read 0x12. It is working.
Test program:
| Code: |
#include <18F27J53.h>
#fuses HS, NOWDT
#use delay(clock=20M)
#use rs232(baud=9600, UART1, ERRORS)
//======================================
void main()
{
int8 i;
int8 write_buffer[64];
int8 read_buffer[64];
printf("Start \n\r");
// Fill write buffer with incrementing data.
for(i=0; i<64; i++)
{
write_buffer[i] = 0x12;
}
// Write the write buffer to flash memory.
write_program_memory(0x400, write_buffer, 64);
// Read it back into a separate read buffer.
read_program_memory(0x400, read_buffer, 64);
// Display the data read from Flash memory.
printf("Bytes read from Flash memory address 0x400: \n\r");
for(i = 0; i < 64; i++)
{
printf("%X ", read_buffer[i]);
if(((i+1) & 7) == 0) // Do a newline every 8 bytes
printf("\n\r");
}
printf("\n\r");
printf("\n\r");
while(TRUE);
}
|
MPLAB reports the 18F27J53's device ID is 01:
| Code: |
PICkit 3 detected
Connecting to PICkit 3...
Firmware Suite Version...... 01.28.90
Firmware type......................PIC18FJ
PICkit 3 Connected.
Target Detected
Device ID Revision = 00000001 |
|
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Sat Apr 01, 2017 12:03 am |
|
|
Thank you very much for your test.
Did you have ASM or binary compiled code ? Thank you. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Apr 01, 2017 12:25 am |
|
|
Hex file:
| Code: |
:10000000A1EF00F05374617274200A0D0000427970
:1000100074657320726561642066726F6D20466C32
:10002000617368206D656D6F7279206164647265BB
:1000300073732030783430303A200A0D0000090004
:10004000F55211E0F6CF88F0F7CF89F0F8CF8AF0BB
:10005000F5509EA8FED7AE6E88C0F6FF89C0F7FFA8
:100060008AC0F8FFECD71200F250036EF29EA6840D
:100070000F01550EA76EAA0EA76EA68200000350B0
:10008000F21200011200D08CF6503F0B006EC00E31
:10009000F6160A0088C001F000660BD0F650010F7A
:1000A00008E1000EF720030B04E1A6880900DCDF5D
:1000B0000A00006607D0EECFF5FF015204E00F0002
:1000C000010603D000060B000C003F0EF6143F0A99
:1000D000E3E1CADF0166E0D7F86ADCEF00F089C02F
:1000E00001F088C000F08867012A0900F5CFEEFF13
:1000F000002EFBD7012EF9D7F86AE7EF00F08ABF90
:1001000010D00F0E006E893900160A0E005C03E253
:10011000300E002602D08A51002600509EA8FED73D
:10012000AE6E0F0E89170A0E895D02E2300E02D004
:100130008A9F8A51892789519EA8FED7AE6EFEEF0D
:1001400000F0F86AD09E046A7E86080EB06E020E39
:100150007F6EA60EAD6E900EAC6E066A056AFF0E3F
:100160000F01486FC29CC29E4951E00B1F09496FA5
:10017000256BD16AD26A040EF66E000EF76E000E81
:10018000F86E00015CDF076A07503F080BE3036A63
:100190000750080FE96E000E0320EA6E120EEF6E94
:1001A000072AF2D7F86A040EF76EF66AEA6A080EB2
:1001B000E96E400E886F67D7F86A040EF76EF66A2C
:1001C000EA6A480EE96E896B400E886F88D70E0E7A
:1001D000F66E000EF76E000EF86E31DF076A0750FC
:1001E0003F081EE3036A0750480FE96E000E032024
:1001F000EA6EEFCF89F0370E8A6F81D7200E9EA866
:10020000FED7AE6E010E0724070B08E10A0E9EA86A
:10021000FED7AE6E0D0E9EA8FED7AE6E072ADFD7B4
:100220000A0E9EA8FED7AE6E0D0E9EA8FED7AE6E2D
:100230000A0E9EA8FED7AE6E0D0E9EA8FED7AE6E1D
:04024000FFD70300E1
:020000040001F9
:08FFF800BEF7F4FFFFFBFFFB65
:00000001FF
;PIC18F27J53
;CRC=3C4F CREATED="31-Mar-17 20:52"
|
|
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Sat Apr 01, 2017 12:46 am |
|
|
Thank you.
Good news ! It work for me too !!!
I take exactly same C code. Compile it, and flash it on hardware pic. Then read memory with PicKit3.
Compiled code is strictly the same as you.
My memory : | Code: |
:1003F000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF0D
:1004000012121212121212121212121212121212CC
:1004100012121212121212121212121212121212BC
:1004200012121212121212121212121212121212AC
:10043000121212121212121212121212121212129C
:10044000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBC
|
So, i could now find why my code not working.
It was too difficult to compare with XC8 compiled code due to multiples implementations differences. But from CCS to CCS, it is easier.
Thank you again ! I will post the result of my investigations. |
|
|
tssir
Joined: 14 Feb 2016
Posts: 24
|
|
| Posted: Sat Apr 01, 2017 2:45 am |
|
|
The answer is : NOWPDIS fuse
Datasheet :
"WPDIS:Write-Protect Disable bit
1= WPFP<5:0>, WPEND and WPCFG bits are ignored; all Flash memory may be erased or written
0= WPFP<5:0>, WPEND and WPCFG bits enabled; erase/write-protect is active for the selected region(s)"
Works with CONFIG4L register and WPEND fuse, to select memory area.
If you want to enable erase/write memory, you need to use WPDIS. Beware the double negation of the register ... |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9232
Location: Greensville,Ontario
|
|
| Posted: Sat Apr 01, 2017 9:06 am |
|
|
interesting... of course today's PICs have more fuses than instructions, so it's super important to read everything about fuses and their default settings.
One programmer's idea of 'default' may not be your idea !
Since migrating to the 18F46K22, I've coded EVERY fuse in an include file. My 'default' file is what worked for the 1Hz LED program. Additional fuse.files are made for specific projects. This does 2 things.One,it's easy to see every fuse,even ones you 'think' you'll never need. Two, less typing ! less chance for wrong fuse settings and main() is less cluttered.
Jay |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Apr 01, 2017 9:54 am |
|
|
I do the opposite. I set the minimal fuses required to run the program,
or setup the PIC the way I want it, and I trust CCS to disable the rest of
them. That is in fact why my program worked and his didn't. I have
certain methods of doing electronics/programming that result in almost
everything I do will work the first time or maybe with a small change. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
