[PIC] 18F EEPROM

[Anthony Nixon]

Hi all,

Still pulling my hair out with this chip.

After 24 hours, no matter what I try, I cannot read/write to internal
EEPROM. I have disabled all available code protection in fuses
including the EEPROM and have followed the data sheet as it says but
all I get back from a read is 0x00 which sort of suggests there is
some protection mechanism I am unaware of, or a fuse bit is being
programmed incorrectly.

More frustratingly, MPLABX reads/writes the EEPROM perfectly.

All used RAM registers are in ACCESS RAM space

;
; --------------------------------
; SUBROUTINE: READ INTERNAL EEPROM - 18F47K40
; --------------------------------
; HI addr in intEEPH, LO addr in intEEPL
RDeeprom movlb 0h ; probably not required
bcf NVMCON1,NVMREG0,A ; Setup Data EEPROM Access
bcf NVMCON1,NVMREG1,A ; Setup Data EEPROM Access
movf intEEPL,W,A
movwf NVMADRL,A ; Setup Address low byte
movf intEEPH,W,A
movwf NVMADRH,A ; Setup Address high byte
bsf NVMCON1,RD ; Issue EE Read
movf NVMDAT,W,A ; W = EE_DATA
return

The PICkit 3 programs/verifies and reads back the eeprom data ok, but
I cannot read the data internally. If I write to EEPROM, nothing
happens also, even after the PICkit reads back.

I have tried on different brand new chips but no joy.

The code is running as I have a 15 digit multiplexed display which
shows data correctly and talks to the PC via USB/serial port no
problem

Any ideas :-)

cheers

Tony

[Forrest Christian (List Account)]

Have you followed the instructions in darasheet section 11.3.4 to the
letter when writing, including the unlock sequence in 11.1.4?

In the past, I've used mplab to init the eevprom to known data in order to
test read code. Only after that works do I move to the write code.

Post by Anthony Nixon
Hi all,
Still pulling my hair out with this chip.
After 24 hours, no matter what I try, I cannot read/write to internal
EEPROM. I have disabled all available code protection in fuses
including the EEPROM and have followed the data sheet as it says but
all I get back from a read is 0x00 which sort of suggests there is
some protection mechanism I am unaware of, or a fuse bit is being
programmed incorrectly.
More frustratingly, MPLABX reads/writes the EEPROM perfectly.
All used RAM registers are in ACCESS RAM space
;
; --------------------------------
; SUBROUTINE: READ INTERNAL EEPROM - 18F47K40
; --------------------------------
; HI addr in intEEPH, LO addr in intEEPL
RDeeprom movlb 0h ; probably not required
bcf NVMCON1,NVMREG0,A ; Setup Data EEPROM Access
bcf NVMCON1,NVMREG1,A ; Setup Data EEPROM Access
movf intEEPL,W,A
movwf NVMADRL,A ; Setup Address low byte
movf intEEPH,W,A
movwf NVMADRH,A ; Setup Address high byte
bsf NVMCON1,RD ; Issue EE Read
movf NVMDAT,W,A ; W = EE_DATA
return
The PICkit 3 programs/verifies and reads back the eeprom data ok, but
I cannot read the data internally. If I write to EEPROM, nothing
happens also, even after the PICkit reads back.
I have tried on different brand new chips but no joy.
The code is running as I have a 15 digit multiplexed display which
shows data correctly and talks to the PC via USB/serial port no
problem
Any ideas :-)
cheers
Tony
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Anthony Nixon]

Hi Forest,

Thanks for the reply.

Yes, exactly as it says, However, it also fails on reads where it
always returns 0x00.

Baffling.

I remodelled the code to store the data in ROM as a test and it worked
fine, so not sure why the EEPROM access is failing.

cheers


Tony

On Sun, Oct 8, 2017 at 4:51 PM, Forrest Christian (List Account)

Post by Forrest Christian (List Account)
Have you followed the instructions in darasheet section 11.3.4 to the
letter when writing, including the unlock sequence in 11.1.4?
In the past, I've used mplab to init the eevprom to known data in order to
test read code. Only after that works do I move to the write code.

Post by Anthony Nixon
Hi all,
Still pulling my hair out with this chip.
After 24 hours, no matter what I try, I cannot read/write to internal
EEPROM. I have disabled all available code protection in fuses
including the EEPROM and have followed the data sheet as it says but
all I get back from a read is 0x00 which sort of suggests there is
some protection mechanism I am unaware of, or a fuse bit is being
programmed incorrectly.
More frustratingly, MPLABX reads/writes the EEPROM perfectly.
All used RAM registers are in ACCESS RAM space
;
; --------------------------------
; SUBROUTINE: READ INTERNAL EEPROM - 18F47K40
; --------------------------------
; HI addr in intEEPH, LO addr in intEEPL
RDeeprom movlb 0h ; probably not required
bcf NVMCON1,NVMREG0,A ; Setup Data EEPROM Access
bcf NVMCON1,NVMREG1,A ; Setup Data EEPROM Access
movf intEEPL,W,A
movwf NVMADRL,A ; Setup Address low byte
movf intEEPH,W,A
movwf NVMADRH,A ; Setup Address high byte
bsf NVMCON1,RD ; Issue EE Read
movf NVMDAT,W,A ; W = EE_DATA
return
The PICkit 3 programs/verifies and reads back the eeprom data ok, but
I cannot read the data internally. If I write to EEPROM, nothing
happens also, even after the PICkit reads back.
I have tried on different brand new chips but no joy.
The code is running as I have a 15 digit multiplexed display which
shows data correctly and talks to the PC via USB/serial port no
problem
Any ideas :-)
cheers
Tony
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

Hi Tony,

I don't like to think how many undocumented bugs I've had to sort
out for myself and tend to stay away from newly-released micros

A couple last year involved the 18F43K20, which may be similar
silicon to your 47K40

I found that whilst most datasheet examples are *substantially
correct* they aren't always perfect. On occasion I've had to alter
the instruction order or insert NOPs because the silicon doesn't
react fast enough, that sort of thing

Maybe try something like adding NOP delays to ensure that register
bits are set/cleared before the next instruction

The first (only ?) errata I could find for the 47K40 is this one

http://ww1.microchip.com/downloads/en/DeviceDoc/80000713C.pdf

which doesn't mention EEPROM but does include a NOP solution
I'd already worked out for the 43K20

HTH

Joe

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Anthony Nixon]

Hi Joe,

Thanks for the help.

I tried to use the exact code example for writing to ROM and the
simulator will erase the ROM but not write data back at all. I tried
fiddling with the code, but no joy so something is definitely screwy
here.

I've been "playing" with it for 30 hours now :-(

cheers

Tony

Post by IVP
Hi Tony,
I don't like to think how many undocumented bugs I've had to sort
out for myself and tend to stay away from newly-released micros
A couple last year involved the 18F43K20, which may be similar
silicon to your 47K40
I found that whilst most datasheet examples are *substantially
correct* they aren't always perfect. On occasion I've had to alter
the instruction order or insert NOPs because the silicon doesn't
react fast enough, that sort of thing
Maybe try something like adding NOP delays to ensure that register
bits are set/cleared before the next instruction
The first (only ?) errata I could find for the 47K40 is this one
http://ww1.microchip.com/downloads/en/DeviceDoc/80000713C.pdf
which doesn't mention EEPROM but does include a NOP solution
I'd already worked out for the 43K20
HTH
Joe
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

something is definitely screwy here

Tony,

of all the bugs I've found ISTR they were all down to a control
register bit needing a workaround, slow response as I mentioned, or
the clock. There was a batch of 18F1320 which were fine with the
4MHz IntOsc but some modules simply didn't work at all at 8MHz
IntOsc. All modules worked perfectly in any other oscillator mode,
including a crystal up to 40MHz

Joe

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Anthony Nixon]

hi Joe,

I'll keep fiddling, and I must be wrong somewhere, surely Microchip
would not have released a chip without a bread and butter feature like
being able to access EEPROM and ROM.

Looking around the web tho, there were some EEPROM issues, but no
answers that I could find

thanks again

Tony

Post by IVP

something is definitely screwy here

Tony,
of all the bugs I've found ISTR they were all down to a control
register bit needing a workaround, slow response as I mentioned, or
the clock. There was a batch of 18F1320 which were fine with the
4MHz IntOsc but some modules simply didn't work at all at 8MHz
IntOsc. All modules worked perfectly in any other oscillator mode,
including a crystal up to 40MHz
Joe
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Neil]

I use the EEPROM successfully on an 18F2xK22 series w/no issue, but I'm
using C. These are my routines in C, and disassembled:

Cheers,
-Neil.


unsigned char EEReadByte(unsigned char address)
{
EEADR = address;
EECON1 = 0; // EEPROM memory, read
EECON1bits.RD = 1; // Initiate read operation
return (EEDATA);
} // EEReadByte()


void EEWriteByte(unsigned char address, unsigned char value)
{
PIR2bits.EEIF = 0; // Clear write-complete flag

EEADR = address; // Filter out only lower byte
EEDATA = value;
EECON1 = 0b00000100; // Setup write to EEPROM
data memory
INTCONbits.GIE = 0; // Temporarily disable
interrupts
EECON2 = 0x55; // Required write sequence
EECON2 = 0xAA; // ...
EECON1bits.WR = 1; // Initiate write
INTCONbits.GIE = 1; // Re-enable interrupts

while (PIR2bits.EEIF == 0); // Wait for completion
EECON1bits.WREN = 0; // Disable writes
} // EEWriteByte










--- C:\Moi\PICDev\18F_K22\DIBase-C\EEroutines.c
------------------------------------------------
1: #include <p18f24k22.h>
2:
3:
4: unsigned char EEReadByte(unsigned char address)
1BA6 CFD9 MOVFF 0xfd9, 0xfe6
1BA8 FFE6 NOP
1BAA CFE1 MOVFF 0xfe1, 0xfd9
1BAC FFD9 NOP
5: {
6: EEADR = address;
1BAE 0EFE MOVLW 0xfe
1BB0 50DB MOVF 0xfdb, W, ACCESS
1BB2 6EA9 MOVWF 0xfa9, ACCESS
7: EECON1 = 0; // EEPROM memory, read
1BB4 6AA6 CLRF 0xfa6, ACCESS
8: EECON1bits.RD = 1; // Initiate read operation
1BB6 80A6 BSF 0xfa6, 0, ACCESS
9: return (EEDATA);
1BB8 50A8 MOVF 0xfa8, W, ACCESS
1BBA D000 BRA 0x1bbc
10: } // EEReadByte()
1BBC 52E5 MOVF 0xfe5, F, ACCESS
1BBE CFE7 MOVFF 0xfe7, 0xfd9
1BC0 FFD9 NOP
1BC2 0012 RETURN 0
11:
12:
13: void EEWriteByte(unsigned char address, unsigned char
value)
1BC4 CFD9 MOVFF 0xfd9, 0xfe6
1BC6 FFE6 NOP
1BC8 CFE1 MOVFF 0xfe1, 0xfd9
1BCA FFD9 NOP
14: {
15: PIR2bits.EEIF = 0; //
Clear write-complete flag
1BCC 98A1 BCF 0xfa1, 0x4, ACCESS
16:
17: EEADR = address; // Filter
out only lower byte
1BCE 0EFE MOVLW 0xfe
1BD0 50DB MOVF 0xfdb, W, ACCESS
1BD2 6EA9 MOVWF 0xfa9, ACCESS
18: EEDATA = value;
1BD4 0EFD MOVLW 0xfd
1BD6 50DB MOVF 0xfdb, W, ACCESS
1BD8 6EA8 MOVWF 0xfa8, ACCESS
19: EECON1 = 0b00000100; // Setup
write to EEPROM data memory
1BDA 0E04 MOVLW 0x4
1BDC 6EA6 MOVWF 0xfa6, ACCESS
20: INTCONbits.GIE = 0; //
Temporarily disable interrupts
1BDE 9EF2 BCF 0xff2, 0x7, ACCESS
21: EECON2 = 0x55; //
Required write sequence
1BE0 0E55 MOVLW 0x55
1BE2 6EA7 MOVWF 0xfa7, ACCESS
22: EECON2 = 0xAA; // ...
1BE4 0EAA MOVLW 0xaa
1BE6 6EA7 MOVWF 0xfa7, ACCESS
23: EECON1bits.WR = 1; //
Initiate write
1BE8 82A6 BSF 0xfa6, 0x1, ACCESS
24: INTCONbits.GIE = 1; //
Re-enable interrupts
1BEA 8EF2 BSF 0xff2, 0x7, ACCESS
25:
26: while (PIR2bits.EEIF == 0); //
Wait for completion
1BEC A8A1 BTFSS 0xfa1, 0x4, ACCESS
1BEE D7FE BRA 0x1bec
27: EECON1bits.WREN = 0; //
Disable writes
1BF0 94A6 BCF 0xfa6, 0x2, ACCESS
28: } // EEWriteByte
1BF2 52E5 MOVF 0xfe5, F, ACCESS
1BF4 CFE7 MOVFF 0xfe7, 0xfd9
1BF6 FFD9 NOP
1BF8 0012 RETURN 0

Post by Anthony Nixon
hi Joe,
I'll keep fiddling, and I must be wrong somewhere, surely Microchip
would not have released a chip without a bread and butter feature like
being able to access EEPROM and ROM.
Looking around the web tho, there were some EEPROM issues, but no
answers that I could find
thanks again
Tony

Post by IVP

something is definitely screwy here

Tony,
of all the bugs I've found ISTR they were all down to a control
register bit needing a workaround, slow response as I mentioned, or
the clock. There was a batch of 18F1320 which were fine with the
4MHz IntOsc but some modules simply didn't work at all at 8MHz
IntOsc. All modules worked perfectly in any other oscillator mode,
including a crystal up to 40MHz
Joe
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

surely Microchip would not have released a chip without a
bread and butter feature like being able to access EEPROM
and ROM

You'd think. I'm sure everyone here has a tale to tell

I've had issues, actual time-wasting silicon issues, with many
basic features (which Microchip will deny until you prove it)

All you can do is persevere

Good luck

---
This email has been checked for viruses by AVG.
http://www.avg.com

[John Gardner]

...All you can do is persevere...

Or switch to AVR, which I did years ago. Would'nt work for many,

but did for me - It should be noted that AVR is not without Sin either.

And that was before they were swallowed by Leviathan...

Post by IVP

surely Microchip would not have released a chip without a
bread and butter feature like being able to access EEPROM
and ROM

You'd think. I'm sure everyone here has a tale to tell
I've had issues, actual time-wasting silicon issues, with many
basic features (which Microchip will deny until you prove it)
All you can do is persevere
Good luck
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Anthony Nixon]

Hi Neil,

Thanks for the help, it would have been some effort to set that reply up.

The 18F47K40 has a slightly different mechanism. It uses register
NVMCOM1 for memory read/writes.

I think I have exhausted all code options. I've swapped code protect
FUSE bits, all the read/write bit combinations for NVMCON but no
success on any of the chips I have.

Just 1 chip has 71 reprogram tries, very time consuming and
frustrating for something that shouldn't be happening. All other code
seems to work fine.

cheers

Tony

Post by John Gardner
...All you can do is persevere...
Or switch to AVR, which I did years ago. Would'nt work for many,
but did for me - It should be noted that AVR is not without Sin either.
And that was before they were swallowed by Leviathan...

Post by IVP

surely Microchip would not have released a chip without a
bread and butter feature like being able to access EEPROM
and ROM

You'd think. I'm sure everyone here has a tale to tell
I've had issues, actual time-wasting silicon issues, with many
basic features (which Microchip will deny until you prove it)
All you can do is persevere
Good luck
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

swapped code protect FUSE bits, all the read/write bit combinations
for NVMCON but no success on any of the chips I have.

Tony,

a problem (of my own making as it turned out) I had with the 14K22
last year meant that the INT0 interrupt wouldn't work. INT0 is about
as fundamental as a hardware function can get

It turned out that I was using a version of MPLAB one version below
what I should have been using for that micro

What happened was that DEBUG was not being turned off by the
assembler build and this prevented INT0 working

Maybe verify in the hex file that what you want is what you got

Here's a note I made at the time, to manually change my hex file

;Set bit7 of config4l (0x3000006) to turn debug off

;Open hex file in Notepad

;:020000040030CA
;:03000100381E1E88
;;02000500880170 changed to :020005008881F0, F0 is 2's complement of line's
byte sum
;:0600080003C003E0034009
;:00000001FF


---
This email has been checked for viruses by AVG.
http://www.avg.com

[Anthony Nixon]

Hi Joe,

Just checked all the fuse data from the HEX file and all is as it
should be, with the exception of the Brownout voltage which is [11]
instead of [00] for the setting I chose, but is disabled anyway.

I know the code works as there is a 15 digit 7 seg LED display
multiplexed with 35 switches, multiple data lookup tables, and 2 way
serial comms to a PC USB port. All that works as expected.

Just the memory access seems to be the sticking point.

I sent a Support Case message to Microchip and if my grey hairs and II
live long enough, hopefully I'll get some sort of reply.:-)

cheers

Tony

Post by IVP

swapped code protect FUSE bits, all the read/write bit combinations
for NVMCON but no success on any of the chips I have.

Tony,
a problem (of my own making as it turned out) I had with the 14K22
last year meant that the INT0 interrupt wouldn't work. INT0 is about
as fundamental as a hardware function can get
It turned out that I was using a version of MPLAB one version below
what I should have been using for that micro
What happened was that DEBUG was not being turned off by the
assembler build and this prevented INT0 working
Maybe verify in the hex file that what you want is what you got
Here's a note I made at the time, to manually change my hex file
;Set bit7 of config4l (0x3000006) to turn debug off
;Open hex file in Notepad
;:020000040030CA
;:03000100381E1E88
;;02000500880170 changed to :020005008881F0, F0 is 2's complement of line's
byte sum
;:0600080003C003E0034009
;:00000001FF
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

Post by Anthony Nixon
I sent a Support Case message to Microchip and if my grey hairs
and II live long enough, hopefully I'll get some sort of reply.:-)

Start holding your breath ..... now

Their favourite trick, which infuriates me like nothing else, is to try
it on a completely different chip and tell me it DOES work

And they like asking questions but not answering them

Several exchanges later, if they haven't already closed the ticket as
Resolved they'll grumpily and reluctantly admit that maybe I'm
right. Maybe

After one particularly annoying lack of action I sent a letter, a
proper printed letter, to the department head

Heard nothing back. That was the last time I went anywhere their
"help" and stick with established chips

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Ryan O'Connor]

Hi Tony, I'm just going to ask the obvious here and ask have you tried a
second chip?

Ryan

Post by IVP

Post by Anthony Nixon
I sent a Support Case message to Microchip and if my grey hairs
and II live long enough, hopefully I'll get some sort of reply.:-)

Start holding your breath ..... now
Their favourite trick, which infuriates me like nothing else, is to try
it on a completely different chip and tell me it DOES work
And they like asking questions but not answering them
Several exchanges later, if they haven't already closed the ticket as
Resolved they'll grumpily and reluctantly admit that maybe I'm
right. Maybe
After one particularly annoying lack of action I sent a letter, a
proper printed letter, to the department head
Heard nothing back. That was the last time I went anywhere their
"help" and stick with established chips
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Harold Hallikainen]

I have not been following this closely, but do you know if the issue is
EEPROM read, write, or both? I'll sometimes use the debugger to run my
write code, then use the debugger to see what's in eeprom. Or use the
debugger to write to eeprom, then run my read code to see if it works.

Good luck!

Harold

Post by Anthony Nixon
Hi Joe,
Just checked all the fuse data from the HEX file and all is as it
should be, with the exception of the Brownout voltage which is [11]
instead of [00] for the setting I chose, but is disabled anyway.
I know the code works as there is a 15 digit 7 seg LED display
multiplexed with 35 switches, multiple data lookup tables, and 2 way
serial comms to a PC USB port. All that works as expected.
Just the memory access seems to be the sticking point.
I sent a Support Case message to Microchip and if my grey hairs and II
live long enough, hopefully I'll get some sort of reply.:-)
cheers
Tony

Post by IVP

swapped code protect FUSE bits, all the read/write bit combinations
for NVMCON but no success on any of the chips I have.

Tony,
a problem (of my own making as it turned out) I had with the 14K22
last year meant that the INT0 interrupt wouldn't work. INT0 is about
as fundamental as a hardware function can get
It turned out that I was using a version of MPLAB one version below
what I should have been using for that micro
What happened was that DEBUG was not being turned off by the
assembler build and this prevented INT0 working
Maybe verify in the hex file that what you want is what you got
Here's a note I made at the time, to manually change my hex file
;Set bit7 of config4l (0x3000006) to turn debug off
;Open hex file in Notepad
;:020000040030CA
;:03000100381E1E88
;;02000500880170 changed to :020005008881F0, F0 is 2's complement of line's
byte sum
;:0600080003C003E0034009
;:00000001FF
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Anthony Nixon]

Hi all,

Boy o boy o boy - in case you can't see, I am cringing on the floor in
the naughty corner sucking my thumb. I think I cracked :-)

It is fixed, now working and totally my fault.

The missing link was the PMD0 register NVMMD bit, I totally missed it.

The bits in these register types (5 in total) are set to 1 on reset
and they have negative logic so the corresponding control is OFF.

This bit controls memory access, which off course was disabled.
Setting it to 0 fixed all of the woes.

My apologies for my stuff up, and sincerest thanks for the help.

One good thing, the PIClist is still a cool place to hang around.

cheers all

Tony




On Mon, Oct 9, 2017 at 3:54 PM, Harold Hallikainen

Post by Harold Hallikainen
I have not been following this closely, but do you know if the issue is
EEPROM read, write, or both? I'll sometimes use the debugger to run my
write code, then use the debugger to see what's in eeprom. Or use the
debugger to write to eeprom, then run my read code to see if it works.
Good luck!
Harold

Post by Anthony Nixon
Hi Joe,
Just checked all the fuse data from the HEX file and all is as it
should be, with the exception of the Brownout voltage which is [11]
instead of [00] for the setting I chose, but is disabled anyway.
I know the code works as there is a 15 digit 7 seg LED display
multiplexed with 35 switches, multiple data lookup tables, and 2 way
serial comms to a PC USB port. All that works as expected.
Just the memory access seems to be the sticking point.
I sent a Support Case message to Microchip and if my grey hairs and II
live long enough, hopefully I'll get some sort of reply.:-)
cheers
Tony

Post by IVP

swapped code protect FUSE bits, all the read/write bit combinations
for NVMCON but no success on any of the chips I have.

Tony,
a problem (of my own making as it turned out) I had with the 14K22
last year meant that the INT0 interrupt wouldn't work. INT0 is about
as fundamental as a hardware function can get
It turned out that I was using a version of MPLAB one version below
what I should have been using for that micro
What happened was that DEBUG was not being turned off by the
assembler build and this prevented INT0 working
Maybe verify in the hex file that what you want is what you got
Here's a note I made at the time, to manually change my hex file
;Set bit7 of config4l (0x3000006) to turn debug off
;Open hex file in Notepad
;:020000040030CA
;:03000100381E1E88
;;02000500880170 changed to :020005008881F0, F0 is 2's complement of line's
byte sum
;:0600080003C003E0034009
;:00000001FF
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Neil]

Well, having been there, I feel for you. But I appreciate you tracking
this down as I've been using the 18F series quite a bit lately, and I'll
probably run into this sometime.

Cheers,
-Neil.

Post by Anthony Nixon
Hi all,
Boy o boy o boy - in case you can't see, I am cringing on the floor in
the naughty corner sucking my thumb. I think I cracked :-)
It is fixed, now working and totally my fault.
The missing link was the PMD0 register NVMMD bit, I totally missed it.
The bits in these register types (5 in total) are set to 1 on reset
and they have negative logic so the corresponding control is OFF.
This bit controls memory access, which off course was disabled.
Setting it to 0 fixed all of the woes.
My apologies for my stuff up, and sincerest thanks for the help.
One good thing, the PIClist is still a cool place to hang around.
cheers all
Tony
On Mon, Oct 9, 2017 at 3:54 PM, Harold Hallikainen

Post by Harold Hallikainen
I have not been following this closely, but do you know if the issue is
EEPROM read, write, or both? I'll sometimes use the debugger to run my
write code, then use the debugger to see what's in eeprom. Or use the
debugger to write to eeprom, then run my read code to see if it works.
Good luck!
Harold

Post by Anthony Nixon
Hi Joe,
Just checked all the fuse data from the HEX file and all is as it
should be, with the exception of the Brownout voltage which is [11]
instead of [00] for the setting I chose, but is disabled anyway.
I know the code works as there is a 15 digit 7 seg LED display
multiplexed with 35 switches, multiple data lookup tables, and 2 way
serial comms to a PC USB port. All that works as expected.
Just the memory access seems to be the sticking point.
I sent a Support Case message to Microchip and if my grey hairs and II
live long enough, hopefully I'll get some sort of reply.:-)
cheers
Tony

Post by IVP

swapped code protect FUSE bits, all the read/write bit combinations
for NVMCON but no success on any of the chips I have.

Tony,
a problem (of my own making as it turned out) I had with the 14K22
last year meant that the INT0 interrupt wouldn't work. INT0 is about
as fundamental as a hardware function can get
It turned out that I was using a version of MPLAB one version below
what I should have been using for that micro
What happened was that DEBUG was not being turned off by the
assembler build and this prevented INT0 working
Maybe verify in the hex file that what you want is what you got
Here's a note I made at the time, to manually change my hex file
;Set bit7 of config4l (0x3000006) to turn debug off
;Open hex file in Notepad
;:020000040030CA
;:03000100381E1E88
;;02000500880170 changed to :020005008881F0, F0 is 2's complement of line's
byte sum
;:0600080003C003E0034009
;:00000001FF
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[IVP]

Thanks for letting us know Tony

---
This email has been checked for viruses by AVG.
http://www.avg.com

[Ryan O'Connor]

Great news and I think we can all relate. Often times learning the hard way
is the best way, I'm just glad you got it. You're really only a master at
something when you have made all the mistakes yourself.

Ryan

Post by IVP
Thanks for letting us know Tony
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[Forrest Christian (List Account)]

Are you using silicon or the simulator?

I haven't found the simulator to be reliable in it's emulation of flash or
eeprom.

Post by Anthony Nixon
Hi Joe,
Thanks for the help.
I tried to use the exact code example for writing to ROM and the
simulator will erase the ROM but not write data back at all. I tried
fiddling with the code, but no joy so something is definitely screwy
here.
I've been "playing" with it for 30 hours now :-(
cheers
Tony

Post by IVP
Hi Tony,
I don't like to think how many undocumented bugs I've had to sort
out for myself and tend to stay away from newly-released micros
A couple last year involved the 18F43K20, which may be similar
silicon to your 47K40
I found that whilst most datasheet examples are *substantially
correct* they aren't always perfect. On occasion I've had to alter
the instruction order or insert NOPs because the silicon doesn't
react fast enough, that sort of thing
Maybe try something like adding NOP delays to ensure that register
bits are set/cleared before the next instruction
The first (only ?) errata I could find for the 47K40 is this one
http://ww1.microchip.com/downloads/en/DeviceDoc/80000713C.pdf
which doesn't mention EEPROM but does include a NOP solution
I'd already worked out for the 43K20
HTH
Joe
---
This email has been checked for viruses by AVG.
http://www.avg.com
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist