Change configuration register from code

[Fabri]

Hello,
I'm wondering how change configuration bit in PIC18F46K22 from code. I can read registers with READ_PROGRAM_MEMORY as user manual say but I can't write back one value. This is my example. I read configurations register and try to change one writing back buffer.

[Ttelmah]

Some of the configuration registers (the ones affecting permissions), can
only be erased by a full chip erase (WRTC). The LVP bit can only be changed in
high voltage programing mode (so by an external programmer), so you
cannot change the whole block of registers as you are trying to do.
If WRTC is set, then no programming of these is allowed.
64 bytes is also trying to program bytes beyond the actual registers.
There are only 14 actual register bytes available (0x300000 to 0x30000D).

[Fabri]

Dear Ttelmah,
Ok, I read 64 byte just to test as example.

In fact I'm thinking to check if WRTC is 0 and then set it to 1 in order to protect them. Can I do that ? in case can you explain how to do ?

[Ttelmah]

You can't.
If WRTC is set, it can only be cleared by a full chip erase.

This is all designed to prevent 'code' from being able to override
protections, or put the chip into an unsupported state.

[Fabri]

In fact to protect configuration registers I must set C0 register so reset bit.

I'm doing some test with application based on PIC18F46K22 where sometimes happens it stop to work and checking device there's no crystal oscillation. I supposed something change configuration bit during work. Do you think it's a possible ?

[temtronic]

I've never come across a PIC that stopped due to a 'fuse' being changed 'all by itself'. You should post your small, compilable test program where this can occur. You say the oscillator stops. Does a scope show this happening ?
Since it's a xtal/2 caps design some possible reasons include:
- Bad PCB design.
- Improperly soldered parts.
- Wrong values of xtal or caps.
- Micro crack in pad/trace.
- Wrong 'fuse' for xtal value.
- Marginal power supply/lack of bypass caps/1 VDD instead of 2 used.

I don't use a real xtal/cap for my 46k22 units unless accurate timing is mission critical. The internal osc has run perfectly fine for years.

Jay

[Fabri]

Really it's a big project I can't post it. I use same fuses configuration from a long time and happens less than 0,01% of production or less and only in some hardware configuration. After reprogrammed, device start to work again so I think there's no hardware problem but I'll consider it. Actually I started to use internal oscillator.

Thanks to give me some informations to work on !

[temtronic]

re:

[Fabri]

Yes, I follow your suggestions and also do some test of oscillator components.

Regards,

[Ttelmah]

Seriously, you need to treat any fuse affecting the oscillator as not
changeable.
Otherwise it is possible to reprogram to a state that won't run with your
hardware.
Changing fuses in general is a bad idea.
What fuse do you actually want to change, and why?.

[Fabri]

as I told you I'm trying to understand why an application stop to work. It happens very rarely. The same firmware works on different hardware with the same components. I have performed EMC immunity tests but the application does not crash. Since the firmware is protected I cannot read it. I noticed on a couple of damaged devices that the oscillator does not start when turned on. If we reprogram them everything will work properly again. If it were a hardware problem, turning off and on again should restart correctly. I was assuming that something changed the configuration bits and so I was thinking of resetting the WRTC bit to protect the configuration bits from accidental changes. However, this is not possible except in the programming phase.

[Ttelmah]

Problem is that you actually have no idea at all if a fuse is changing. It
is just as likely, that in fact the code is getting damaged. So protecting
the fuse would gain nothing. However if the chip is protected the people
setting this up should have protected the fuses as well.
How old are these chips?. The flash program memory, can slowly self
erase.

Does anything in the code perform a write to the program memory?.
A brownout when this is being done, can easily lead to memory corruption.

Brownouts themselves, if BOR is not enabled can also cause damage to the
program memory.

How is the MCLR line wired?. If this can spike at all above the supply, then
a programming cycle can be triggered.

[Fabri]

This forum is interesting especially because open my mind in order to consider different scenarios.
so:
Micro are new and now we have 2019 data code. Sometime happens on device working from 3-4 years and more. I think don't depends from datacode.
MCLR is standard configuration from linear regulator 5Vdc. I tested alot hardware with EMC test and never happens in program memory and eeprom in case of burst.
Bor and powerup timer are enabled. Really BOR level is setted to 1,9V, it's quite low... what do you think about it ? may be this ?
This how I set fuses with 16Mhz Crystal

[Ttelmah]

Raise your Vbor voltage.

The EEPROM write requires a minimum of 2.2v. Trying to start one with
the supply below perhaps 2.4v, is 'asking for trouble'. 1.9v is too low
(should only be set this low on chips that do not attempt to write to the
program memory).
Honestly 2.5v, is a much safer level.
Unless you have a supply that is not reliably above this level, setting
Vbor low is not a sensible things to do.

Is there any way you can ensure the supply is reliable when doing the
write?.

[temtronic]

As a controlled test, I'd take 2 or 3 known 'problem' units, reprogram to use the internal clock, same speed as the xtal version. Run them for a few hours or days,next to another known bad unit. If the original fails and the others perform 100%, then it's probably the real xtal/caps/PCB that's the problem.

Different xtals require different 'drive' (power) to operate, as well so need a resistor in series. This is noted in section 2.5.3 of the datasheet with ref. to detailed Microchip appnotes. The osc will stop if put to sleep,any chance your code tells it to 'sleep'.

This is a hard problem to debug, perhaps cut a very,very small program( 1Hz LED ?) that actually fails. At the very least test with the internal RC osc.
If it fails WITH the internal osc. it's more information that is important to know.

Jay