Problem with internal memory in PIC18F27J53

[Ttelmah]

It is necessary. Otherwise it'll attempt to put other const variables into the reserved area. It resets the ORG for everything.

The buffering is not necessary _provided there is enough memory space to 'lose' this block_. The _whole_ block gets erased. It's a balancing act though. To add the code for the buffering, you would need a RAM buffer for the whole page, and a lot of extra code to read the page and write it back. The size of this may well use up nearly as much as you save.

This is the 'problem' of using the flash program memory....

[spilz]

Ho I see,
so with the config setings for my bootloader, I have no other choice that "lost" 2 pages...

I will try this

You are always here to help us, thanks you so much for that !!

[Ttelmah]

Seriously, I still think you should 'think again', and change the clock rate another way. If you lose power during the config write, then the chip will have to be reprogrammed with an external programmer. It is a dangerous thing to do. One of the reasons it is so complex, is that Microchip do not expect this to be done. It's a wrong/dangerous approach.

[spilz]

I reply to you here:http://www.ccsinfo.com/forum/viewtopic.php?t=54048

[spilz]

Hello,

I use the code that Ttelmah gave, the job is done, I'm able to write and read data and don't lose them when restart.

BUT I get randomly MCLR restart.

I try without the code, with only global variables, everything is going well, and with this code I get this issue (every 1 or 2 min).
I use ams1117 to have 3.3v and I checked with oscilloscope, MCLR always stay at 3.3v.

Someone as an idea about this issue ?

Thanks for your help.

[PCM programmer]

Post a schematic or describe your MCLR circuit.

[spilz]

It's just a 10k resistor between 3.3v and MCLR.

[PCM programmer]

I think random MCLR resets will be caused by:

1. ESD from static electricity.

2. Noise on Vdd or on ground. This could be caused by external circuits,
for example, relays. Or it could be caused by poor board layout.
Typically this would be very thin and long and isolated tracks for Vdd
and ground. The solution would be to use power and ground planes
or at least "grid" the power and ground tracks, and fatten them up.

3. You could be missing the 100 nF capacitor to ground, on all the PIC's
Vdd pins. Also, on all the AVdd pins.

4. If you're running with an ICD or Pickit type programmer connected
to the board, it could possibly be caused by something wrong with
the programmer. Try disconnecting it while testing.

5. It possibly could be caused by floating input pins on the PIC. Try
setting all unused pins to a low level with the output_low() function.

[spilz]

The oscilloscope doesn't show any change on MCLR...

When I say "MCLR restart", it's based only on reading reset_cause when restart.

And it's only when implement this code.

So, is it possible that the restart is caused by a wrong write/read on program memory and that the reset_cause is wrong ?

[Ttelmah]

Seriously, a PIC reset pin, will respond to noise, that nothing but the very fastest sampling scopes can see. I've seen a 1nSec spike cause a reset. Especially anything that takes the line even fractionally _up_.
The MCLR pin on most PIC's (doesn't apply to the newest chips that only program at low voltages), does not have any protection circuitry present. A spike that takes this up, even a small fraction of a volt, starts to engage the circuitry inside the PIC for programming, and it will then reset. It records this as an MCLR reset. This is why it is worth having a resistor/capacitor/diode reset circuit on this pin (the diode across the resistor, which prevents the pin going significantly above the supply, and also ensures the capacitor is quickly discharged when the supply droops). This is also why you can get an 'MCLR reset', on a PIC with MCLR disabled....
Be aware also that the threshold for MCLR is high. Typically about 4v on most of the 5v chips.

However, that being said, you will see a reset as a MCLR reset, if you jump to the start of memory. MCLR reset means that none of the reset 'flags' are set. These are BOR (brownout), POR (power on reset), TO (watchdog timeout), PD (part was asleep), STKFUL (stack overflow), and STKUNF (stack underflow). If _none_ of these are set, it is flagged as an MCLR reset. So if you arrive at the restart_cause call, with none of these set, it'll be flagged as an MCLR reset.
Things to check. Do you have STVREN enabled?. If not, then the stack could be underflowing/overflowing, resulting in a random jump, and not getting flagged. Then remember that the write to program memory, causes the processor to _stop_ (completely). What happens if several interrupt sources are all cued waiting for handling when the processor restarts?. After the write, when you re-enable interrupts, are you sure you are not enabling an interrupt which does not have a handler?.

[spilz]

I tested it with different power supply, battery, stabilized power sources, separate power sources for pic VCC and MCLR, It always appears only when I include this library in my code, randomly, and never when I use global variables (but they are lost when I disconnect power, so they are not the solution).
According to your explanation, I'm still thinking it's maybe not a real MCLR restart.

Yes STVREN is set as #fuse

I don't see where I can find all the 'flags' you listed for reset cause, I only find these in the 18F27J53.h :

[Ttelmah]

These are the internal _processor_ bits, that restart_cause tests, to set the value it returns. Read the data sheet.

Interrupts _must_ always be completely disabled before performing a write to program memory. Again in the data sheet. You also want to prevent things like serial data arriving during the write. The processor stops completely. This is why the standard bootloader uses the XON/XOFF handshake, to stop transmission, while it writes a line. If this is not enabled in the PC, and it keeps sending, this will cause a crash.

Only necessary for writing. Reading has no problems at all (reading is used all the time, when you access a 'const' array for example). It is only the write. From the data sheet:

"7.5.1 FLASH PROGRAM MEMORY WRITE
SEQUENCE
The sequence of events for programming an internal
program memory location should be:
1. Read 1024 bytes into RAM.
2. Update data values in RAM as necessary.
3. Load the Table Pointer register with address
being erased.
4. Execute the erase procedure.
5. Load the Table Pointer register with the address
of the first byte being written, minus 1.
6. Write the 64 bytes into the holding registers with
auto-increment.
7. Set the WREN bit (EECON1<2>) to enable byte
writes.
8. Disable interrupts.
9. Write 55h to EECON2.
10. Write 0AAh to EECON2.
11. Set the WR bit; this will begin the write cycle.
12. The CPU will stall for the duration of the write for
TIW (see parameter D133A).
13. Re-enable interrupts.
14. Repeat steps 6 through 13 until all 1024 bytes
are written to program memory.
15. Verify the memory (table read).
"

Item 8. And look at what item 12 then says happens.