WRITE prob during power cycle 18f6722

[jason]

latest versions, 18f6722, pickit 2


ok, heres the deal. Everything is hunky doory until you switch the machine off and on again, It somtimes will write to the eeprom when it shouldn't.

So I looked at the datasheet and theres several things on this prob. It talks about "WREN" and here at this forum I found this

ASM
bsf EECON1, WR
nop
bcf EECON1, WREN
endasm

the datasheet also talked about several other things so i put them in my inc file

NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
LIST
LIST p = 18F6722, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F6722.INC" ; MPASM Header
__CONFIG _CONFIG1H, _OSC_HS_1H ; _OSC_XT_1H
__CONFIG _CONFIG2L, _PWRT_ON_2L & _BOREN_NOSLP_2L & _BORV_1_2L
__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
__CONFIG _CONFIG3H, _MCLRE_ON_3H
__CONFIG _CONFIG4L, _LVP_OFF_4L & _XINST_OFF_4L
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 64

Strangly enough I had the same issue with another project and fixed it by getting rid of the power capacitor.


the WREN I dont really understand, I prefer basic ver asm. can someone help me out here to understand this a bit.

[Bruce]

Strangly enough I had the same issue with another project and fixed it by getting rid of the power capacitor.

If you have a routine that's writing to EEPROM, and a large value cap on the power rail, it
may still have enough time to write to EEPROM before the cap discharges after removing
power.

Or, are you saying, you get writes on power down without any routine in your code that
writes to EEPROM?

the WREN I dont really understand

WREN is a bit in EECON1, that, when set, allows writes to Flash program or data EEPROM.

Normally this bit will be set at the start of an EEPROM write routine, and then cleared once
the write is complete.

[jason]

I have brown-out on and i have tried several settings, but it dosn't help. I believe I need to use WREN and write together. Heres a direct quote from the datasheet.

"There are conditions when the device may not want to
write to the data EEPROM memory. To protect against
spurious EEPROM writes, various mechanisms have
been implemented. On power-up, the WREN bit is
cleared. In addition, writes to the EEPROM are blocked
during the Power-up Timer period (TPWRT,
parameter 33).

The write initiate sequence and the WREN bit together
help prevent an accidental write during brown-out,
power glitch or software malfunction."

I believe this is exactly what I need. But its all in ASM.

CLRF EEADR ; Start at address 0
CLRF EEADRH ;
BCF EECON1, CFGS ; Set for memory
BCF EECON1, EEPGD ; Set for Data EEPROM
BCF INTCON, GIE ; Disable interrupts
BSF EECON1, WREN ; Enable writes
Loop ; Loop to refresh array
BSF EECON1, RD ; Read current address
MOVLW 55h ;
MOVWF EECON2 ; Write 55h
MOVLW 0AAh ;
MOVWF EECON2 ; Write 0AAh
BSF EECON1, WR ; Set WR bit to begin write
BTFSC EECON1, WR ; Wait for write to complete
BRA $-2
INCFSZ EEADR, F ; Increment address
BRA LOOP ; Not zero, do it again
INCFSZ EEADRH, F ; Increment the high address
BRA LOOP ; Not zero, do it again
BCF EECON1, WREN ; Disable writes
BSF INTCON, GIE ; Enable interrupts

The question is how do I only write my two Variables to eeprom if all is well (within voltage range). One of these variables is a byte and the other is a word.

As to your questions, This is a modification of a machine. I can't remove any capacitors from the power supply like i could in the other project that had the same issue. I would like to resolve this problem once and for all, not for just this project but also for all projects to come.

I do write to the eeprom. but i do not want to write if the system is powering down or up.

Thank you for your time....

[Bruce]

I wouldn't bother with assembler since PBP has WRITE. That should be all you need.

WREN is clear on power-up so I'm not sure how spurious writes would happen at POR.

You could clear EECON1 at power-up with EECON1 = 0 just in case.

This 18F part has a high/low voltage detect, comparators, and several settings for the
brown-out-reset voltage, so you have quite a few options.

If you have a spare input, and can use it to allow EEPROM writes only when a button is
pressed, it would be a good test. Maybe even blink an LED before & after an EEPROM
write. Then you could monitor the LED to see where the un-intended write was taking
place.

[Darrel Taylor]

The code shown from the data sheet will "Refresh" the entire EEPROM space.
It's a procedure that should only be done once every couple month/years in order to meet the 40 year data retention spec. I don't think that's what you're looking for

But in that code, you can also see the required Write Sequence that involves setting 3 bits in EECON1, writing 55h AAh to EECON2, before setting the WR bit in EECON1 which actually initiates the write.

The sequence was designed to prevent any unintentional writes, and it's unlikely that writes to EEPROM on power-up are due to PIC registers not being set properly. And, like Bruce says, that sequence is already included in PBP's WRITE command, so there's no need to do it separately in ASM.

However, there is a minimum voltage requirement for EEPROM writes. And if you are trying to write to EEPROM immediately on power-up to record the number of times it's been powered on/off for instance, then Large capacitors on the power rail may not have fully charged by the time it starts trying to write. This could cause unpredictable results.

The current Brown-out detector settings in your config are ...

_BOREN_NOSLP_2L ; Brown-out Reset enabled in hardware only and disabled in Sleep mode (SBOREN is disabled)

Using the "No Sleep" BOR mode, implies that you may be using Sleep Mode on your board. Perhaps there's a battery backup that keeps it running when there's no power?

If that's the case, then BOR will be disabled, and when main power is restored, it may try to write before the voltage is above the minimum.

_BORV_1_2L ; second highest voltage setting

The "second highest voltage setting" can switch anywhere between 4.11 and 4.55V. If that particular chip switches at the low end of the range, it could also be writing with a low voltage.

If any of this is actually relevant to your problem, then a simple pause 1000 (or less) at the beginning should take care of it. Or, any other method that insures voltage is sufficient, before attempting to write.

HTH,

[jason]

The machine I am modifying sends a signal at power down not when powering up(I have a "pause 2000" when powering up). This signal is a glitch. And I do not want to record this signal. It is not always there otherwise I would just subtract it from the total at power up.

So I'm trying to figure a way to not record this if the voltage is under, lets say 4.5v. The power supply is 5v, so anything under 4.5 would mean it is powering down. It may need to be a bit higher but I'm not sure.

I kind of thought that was what Brown-out was for, but it dosn't seem to be doing any good.

I put a loop with a variable to help this problem, and it has cut back alot of the false writes.

TOTALTEMP=TOTALTEMP+1
IF TOTALTEMP>200 THEN
READ 8,MONEY
IF MONEY <> CREDIT THEN
WRITE 8,CREDIT
GOSUB WRTOTAL
TOTALTEMP=0
ELSE
ENDIF
TOTALTEMP=0
ELSE
ENDIF

But it still dose a false write every once in awhile, before it was almost every shutdown.

Also, There is no battery backup. when this machine shuts down, the pic also is shutting down. however the pic can run as low as I think 2 volts. so any false readings from a pin could cause the pic to write and I dont want to.

[mackrackit]

A similar problem was talked about here. http://www.picbasic.co.uk/forum/showthread.php?t=5649
The question was how to write data as the power was being cut. Same thing but backwards for you.

Use a comparator to monitor the voltage and make your own brown out control.

Use a backup battery and monitor the machine power, when machine power is cut the PIC will then go into a shut down sequence shutting off the battery power.

I think this is the closest thing to "fail safe" you will get, think of a good UPS system with voltage monitoring on a server.