configuration mem

[kmp84]

Hello !

Is it true way to read configuration fuse memory on PCM device 16F1459?

[Ttelmah]

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.

[kmp84]

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

[Ttelmah]

Several fuses are defaulting.
Look at the end of the .lst file to see what is actually being sent to the chip.

[kmp84]

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

[Ttelmah]

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.

[kmp84]

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,

[Ttelmah]

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.

[RF_Developer]

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.

[Ttelmah]

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....

[kmp84]

[Ttelmah]

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).

[kmp84]

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