![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
configuration mem |
Posted: Sun Nov 29, 2015 11:39 am |
|
|
Hello !
Is it true way to read configuration fuse memory on PCM device 16F1459?
Code: |
printf("\n\rProgram Memory Address: 0x8007 -> %LX !",read_program_eeprom(0x8007));
printf("\n\rProgram Memory Address: 0x8008 -> %LX !",read_program_eeprom(0x8008)); |
I change my fuses settings but printed data is the same.
Compiler ver. 5.045 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Sun Nov 29, 2015 12:08 pm |
|
|
The configuration memory, is not actually 'at' address 8000+.
The address is the address used by a _programmer_ to talk to it.
So you have a location that corresponds to the EEPROM (on chips that have EEPROM), and this is used by the programmer, but to talk to this from the code, you have to use read_eeprom. Similarly for the configuration memory, the programmer writes data at the 0x8000 addresses to this, but in the code there is a separate function 'read_configuration_memory'.
The functions to read this memory have to set different bits in the control registers to access this memory. It is not inside the range addressable by the read_program_memory function. |
|
![](templates/subSilver/images/spacer.gif) |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
|
Posted: Sun Nov 29, 2015 12:58 pm |
|
|
Ok, I tried this code with change fuse: PUT-> NOPUT, BROWNOUT-> NOBROWNOUT, but result data are the same:
Config Words: FF 3F FF 3F FF 3F FF 3F 20 28 05 10 23 30 E4 19
Config Words: FF 3F FF 3F FF 3F FF 3F 20 28 05 10 23 30 E4 19
Code: |
#include <16F1459.h>
//#device *=16
#fuses NOPROTECT,NOMCLR,NOPUT,NOWDT,NOBROWNOUT,NOFCMEN
#use delay(int=8MHz, clock=48MHz, USB_FULL, act=USB)
#use rs232(baud=9600, xmit=PIN_B7, rcv=PIN_B5, errors)
void main(){
char buff[16];
int8 i;
read_configuration_memory(buff, 16);
printf("\n\rConfig Words: ");
for(i=0;i<16;i++){
printf(" %X",buff[i]);
}
for(;;){
}
} |
|
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Sun Nov 29, 2015 2:13 pm |
|
|
Several fuses are defaulting.
Look at the end of the .lst file to see what is actually being sent to the chip.
Code: |
#fuses NOPROTECT, NOMCLR, NOPUT, NOWDT, NOBROWNOUT, NOFCMEN
#fuses NODEBUG, NOCLKOUT, NOLVP, NOIESO
#use delay(int=8MHz, clock=48MHz, USB_FULL, act=USB)
|
Look at the lst file and compare the values here with bytes 8&7 (2820) and 10&9 (1005). These are the fuses - there will be bits different (bits 2 & 3 in the second word don't actually exist, so will default to '1'. |
|
![](templates/subSilver/images/spacer.gif) |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
|
Posted: Sun Nov 29, 2015 3:51 pm |
|
|
Hi Mr. "Ttelmah",
I change the settings and the end of .lst file words was changed, but the 'read_configuration_memory' function read the same data:
20 28 05 10
Configuration Fuses:
Word 1: 1E84 INTRC_IO NOWDT PUT NOMCLR NOPROTECT BROWNOUT NOCLKOUT IESO NOFCMEN
Word 2: 1FC3 NOWRT NOCPUDIV LS48MHZ PLL3X PLLEN STVREN BORV19 NOLPBOR NODEBUG NOLVP
Configuration Fuses:
Word 1: 1EC4 INTRC_IO NOWDT PUT MCLR NOPROTECT BROWNOUT NOCLKOUT IESO NOFCMEN
Word 2: 1FC3 NOWRT NOCPUDIV LS48MHZ PLL3X PLLEN STVREN BORV19 NOLPBOR NODEBUG NOLVP |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Mon Nov 30, 2015 4:53 am |
|
|
How are you actually testing this?. Chip, or debugger/sim?.
Reason I ask, is that I have just put the project together and tested in MPLAB SIM. The compiler correctly loads the address as 0, and sets the CFGS bit (which is the 'flag' to say 'access the configuration space'), yet the simulator returns the bytes from the bottom of the program memory instead!...
Just in case the compiler was doing something silly (though I could not see anything wrong), I then wrote a duplicate of the Microchip example program to read the configuration memory, and ran this instead. It gave exactly the same result.
So, possibilities:
1) The simulator is faulty in how it handles this - most likely....
2) Possibly the chips are as well.
3) Could be an error in the data sheet about how to do this - both CCS and I are obviously working from the same 'hymn sheet' here.
So are you testing on a chip, or simulator?. Given that '1' is the most likely problem, if you are testing in a sim, then try a real chip instead. |
|
![](templates/subSilver/images/spacer.gif) |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
|
Posted: Mon Nov 30, 2015 10:19 am |
|
|
I tested above example on real target. I'm using CCS ICD-U64 and now saw that the problem present when I'm in debug mode! When only program target with ICD-U64 the configuration array is changed with change in fuses!
The reason to read fuses is because I want to add this data to program memory check sum. Is it good way to do this and actually which bytes I have to read for fuses ?
Thanks, |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Mon Nov 30, 2015 11:11 am |
|
|
Ah ha...
Understand that lots of fuses have to be set to particular values to debug. When debug is selected, these are automatically switched to the values that debug needs.
Bytes 14,15,16 & 17
The values are actually 14bit values, with byte 14 having the whole 8 bits, and byte 15 having only 6 bits. Same for 16 & 17.
Now you need to be very careful, since the top two bits will be read as the default value, and won't match what is in the code being written.
Why not use the automatic checksum ability?.
#ID checksum, will write a checksum of the whole code (including the fuses), into the device ID bytes. These are the ones in the first 8 bytes of the configuration memory. |
|
![](templates/subSilver/images/spacer.gif) |
RF_Developer
Joined: 07 Feb 2011 Posts: 839
|
|
Posted: Mon Nov 30, 2015 11:13 am |
|
|
The fuses in debug mode will be different from normal release code. This is normal: they have to be different to support the debugging.
I do checksum testing in most of my code. I turn off the function in debug mode. I do not attempt to check the fuses. One reason being, in many cases, if the fuses are wrong, the code is pretty much dead in the water.
So far, with well over a thousand copies produced, I have never yet detected any checksum failure in running code. I have sometimes seen code that's half programmed not running at all, but if it run at all, it appears to be right. Most programmers will erase the fuses early but write them last, so if anything goes wrong with the programming, the fuses don't get written and the PIC won't run, or will be so far off "right", e.g. totally wrong clock source, that it doesn't run.
With bootloaders, its very strongly recommended not to write the fuses, and that therefore the bootloader has to be written so that it uses the same fuse configuration as the application code. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Mon Nov 30, 2015 11:26 am |
|
|
Yes.
It is well worth looking at the data sheet for the chip. In most cases, the fuses actually cannot be written by the flash memory write functions in the code. There is normally a little table, giving device ID as writable from both code, and programmer. Chip ID/revision, as not writable from either, and fuses as only writable by the programmer. Attempting to write the fuse page, therefore won't cause problems, but if the fuses differ, you will then get a failure from the bootloader, when the bytes don't match what you are attempting to write.... |
|
![](templates/subSilver/images/spacer.gif) |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
|
Posted: Tue Dec 01, 2015 3:27 am |
|
|
Ttelmah wrote: |
#ID checksum, will write a checksum of the whole code (including the fuses), into the device ID bytes. These are the ones in the first 8 bytes of the configuration memory. |
The "#ID CHECKSUM" is good option for me. When I program PIC with example code below result bytes are:
Config Words: 0F 00 0B 00 08 00 00 00 (first eight byte?)
1.Is the checksum are 16 bits, how to get only checksum?
2.At the end of my hex file have this data:
;PIC16F1459
;CRC=552E CREATED="01-дек-15 11:14"
How to get this CRC ? If two checksum are equal, it will be the best for compare file CRC and #ID CRC.
Code: |
#include <16F1459.h>
#fuses NOPROTECT,NOMCLR,NOPUT,NOWDT,NOBROWNOUT,NOFCMEN
#use delay(int=8MHz, clock=48MHz, USB_FULL, act=USB)
#use rs232(baud=9600, xmit=PIN_B7, rcv=PIN_B5, errors)
#id CHECKSUM
void main(){
char buff[16];
int8 i;
read_configuration_memory(buff, 16);
printf("\n\n\r Config Words: ");
for(i=0;i<16;i++){
printf(" %X",buff[i]);
}
for(;;){
}
}
|
Thanks for your help! |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19381
|
|
Posted: Tue Dec 01, 2015 8:14 am |
|
|
The checksum, is just a checksum, not a CRC. Take all the instruction words one by one, and just add them up. Subtract this from 0x1248. You can also put the checksum somewhere else (if (for instance) you want to include it in the main code, so you don't have to touch the ID bytes). So (for instance):
#ROM 0x1000=checksum
Puts a checksum at 0x1000. You could use somewhere near the top of the ROM like 0x1FE0.
ex_checksum.c checks the checksum on a chip.
It is stored in the ID as 'nibble by nibble'. So is 0x08BF for your example.
On your chip it is only the low 14bits (since instructions are only 14bit in size). |
|
![](templates/subSilver/images/spacer.gif) |
kmp84
Joined: 02 Feb 2010 Posts: 345
|
|
Posted: Tue Dec 01, 2015 9:41 am |
|
|
Hello
Why data stored with "#id checksum" and " #ROM 0x1FE0=checksum " are different ?
Config Words: 05 00 0E 00 0B 00 04 00
SUM_AT 0x1FE0: 1D59 |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|