EEPROM losing contents after power cycle

[kcsl]

I have 5 identical devices using a PIC18F27Q83, all loaded with the same identical software.

Three of them seem fine, but two devices lose the EEPROM contents when the power is cycled.
I did find something that said you need a small delay at power on before accessing the EEPROM, so I added a 100ms delay before I read the EEPROM but it didn't help.

I thought that perhaps the EEPROM wasn't being written, but the device accepts data from the PC, stores it in EEPROM and then executes a reset to restart the PIC and this loads the data back and it's still there and intact. It's just the power cycle that is destroying the contents.

Has anybody else had this weird issue.

Regards,
Joe

[kcsl]

I can't delete the above post.

It's not the EEPROM... there is something else  strange going on but it's not the EEPROM.
I added a serial connection to the device and dumped the contents and it looks fine.

It must be some weird timing issue, but it's weird how it's always the same two devices that don't work.

[trastikata]

It is possible that 100ms aren't sufficient for proper boot since they are counted as oscillator cycles in the assembler code.

The specifications say for proper re-boot the devices need 65 ms but this is characterized and not tested, while the the oscillator need 1024 cycles to stabilize.

So when does the program counter start counting the 100 ms delay? Is the VCC rise fast enough to guarantee that time. Does the oscillator start much earlier than other peripherals which might need higher voltage.

We are not sure what happens and if the 100ms is actually enough. 100ms is too close to the 65ms delay which is in addition to that not guaranteed to be sufficient in terms of program cycles.

Try 250 ms delay and see if it works, if it does then you got the answer to the problem, if not we can brainstorm other possible reasons.

[kcsl]

Well I found the problem. Nothing to do with the EEPROM in the end, rather a stupid mistake by me.

I created a procedure that returns a value, but within the procedure it never actually set the return value, so seemed to return a random value.

Bizarrely on 3 devices it always returned 0 so worked correctly, but on two PIC devices it returned a large random number that was causing other issues down the line.

I looked at the code several times and never spotted it, and in desperation threw the assembler listing at chatGPT and it figured it out.

Code Select Expand

I dug through your .LST — this isn't a compiler ghost. There's one specific place where you do overwrite gnAC_State right after setting it correctly.

What's happening

gnAC_State is at 0x58C (gnAC_State equ 0x58C).

You set it to constants in several places (e.g., movwf gnAC_State with 2, 4, 5, 6, ...). All good.

But here you do:
gnAC_State = _CPROC_ ValidateACChallenge()
which generates:

_mcall ValidateACChallenge
movff ValidateACChallengeResult, gnAC_State


(at 0x4236: C6C0 F58C movff ValidateACChallengeResult,gnAC_State)

Inside ValidateACChallenge you already set gnAC_State yourself to AC_State4 or AC_State2 (see 0x8844 and 0x886A, the movwf gnAC_State with 4 or 2). But the function then returns 0 (return 0 ; EndProc), so when you get back, the assignment gnAC_State = (function result) clobbers the correct state with 0.

That explains the "it's being overwritten with an incorrect value" symptom exactly."

Anyway, I fixed that, but I've also taken on board what you said about the EEPROM timings. I do have code to wait for the oscillator to be stable before moving on, but at this point in the code a 200ms delay won't be noticed so I've added that.

Thanks for your help.

Regards,
Joe

[Dompie]

..... and in desperation threw the assembler listing at chatGPT and it figured it out.

Wow, that's a really useful use of chatGPT!! I never thought of using chatGPT like that. Clever. Thanks.

Johan