[PIC] 16F18854 WRITE to EEPROM in Assembly

[James Wages]

I am trying to figure out how to WRITE data the initial EEPROM address on a 16F18854 using Assembly code. Sadly, the datasheet is lacking in terms of clarity:

http://ww1.microchip.com/downloads/en/DeviceDoc/40001826B.pdf

Please open the datasheet PDF to page 153. Section 10.2 Data EEPROM Memory says, "Data EEPROM Memory consists of 256 bytes of user data memory. The EEPROM provides storage locations for 8-bit user defined data." If truly only "8-bit" then why is the NVMDATH:NVMDATL register pair (16-bits) required to WRITE to EEPROM? In other words, if truly 8-bit, am I allowed to WRITE to only to the Low Byte, NVMDATL?

Second related question...

The following is some ASM code I wrote. Does it look correct? Or have I written something wrong or out of sequence?

; ---------------
; WRITE to EEPROM
; ---------------
; * EEPROM Code-protection must be disable to READ/WRITE (Config5 -> "_CPD_OFF")

; EEPROM Address Setup:
banksel NVMCON1 ; [Bank 16]
bsf NVMCON1, NVMREGS ; Access EEPROM.
bsf NVMCON1, WREN ; Allow Program/Erase.
movlw b'11110000' ; Address High Byte for WRITE to F000h.
movwf NVMADRH
clrf NVMADRL ; F000h = 11110000 00000000
; Data to WRITE to EEPROM address above:
movlw b'00000001' ; Low Byte data to WRITE
movwf NVMDATL
movlw b'10000000' ; High Byte data to WRITE
movwf NVMDATH
; Unlock Sequence (required for WRITE to EEPROM):
bcf INTCON, GIE ; Disable Interrupts (important)
; Next line not needed because WREN was already set to 1 above?
; bsf NVMCON1, WREN ; Enable WRITE/ERASE.
movlw 0x55 ; Put 55h into NVMCON2 register.
movwf NVMCON2
movlw 0xAA ; Put AAh into NVMCON2 register.
movwf NVMCON2
bsf NVMCON1, WR ; Set WR bit to begin WRITE/ERASE.
bsf INTCON, GIE ; Re-enable Interrupts.
WRITEwater
btfsc NVMCON1, WR ; WRITE finished?
goto WRITEwater ; No. Loop.
goto MainProgram ; Yes.


Thank you,

James Wages

[James Cameron]

Post by James Wages
I am trying to figure out how to WRITE data the initial EEPROM
address on a 16F18854 using Assembly code. Sadly, the datasheet is
http://ww1.microchip.com/downloads/en/DeviceDoc/40001826B.pdf
Please open the datasheet PDF to page 153. Section 10.2 Data EEPROM
Memory says, "Data EEPROM Memory consists of 256 bytes of user data
memory. The EEPROM provides storage locations for 8-bit user defined
data." If truly only "8-bit" then why is the NVMDATH:NVMDATL
register pair (16-bits) required to WRITE to EEPROM?

Because the NVM peripheral accesses more than the EEPROM, and there
must be a way to disambiguate that access.

Because the address decoder described by Table 10-2 NRM ORGANIZATION
says that access to EEPROM requires an NVMDATH value of F0h.

Post by James Wages
In other words, if truly 8-bit, am I allowed to WRITE to only to the
Low Byte, NVMDATL?

Provided you have written F0h to NVMDATH, probably yes.

Should any code write a different value to NVMDATH, no.

Post by James Wages
Second related question...
The following is some ASM code I wrote. Does it look correct? Or
have I written something wrong or out of sequence?

See below.

Post by James Wages
; ---------------
; WRITE to EEPROM
; ---------------
; * EEPROM Code-protection must be disable to READ/WRITE (Config5 -> "_CPD_OFF")
banksel NVMCON1 ; [Bank 16]
bsf NVMCON1, NVMREGS ; Access EEPROM.
bsf NVMCON1, WREN ; Allow Program/Erase.
movlw b'11110000' ; Address High Byte for WRITE to F000h.
movwf NVMADRH
clrf NVMADRL ; F000h = 11110000 00000000
movlw b'00000001' ; Low Byte data to WRITE
movwf NVMDATL
movlw b'10000000' ; High Byte data to WRITE
movwf NVMDATH
bcf INTCON, GIE ; Disable Interrupts (important)
; Next line not needed because WREN was already set to 1 above?
; bsf NVMCON1, WREN ; Enable WRITE/ERASE.

I'm not convinced it is not needed. Example 10-2 NVM UNLOCK SEQUENCE
says it should be there. Don't speculate, test.

Post by James Wages
movlw 0x55 ; Put 55h into NVMCON2 register.
movwf NVMCON2

Trailing spaces are awful. ;-)

Post by James Wages
movlw 0xAA ; Put AAh into NVMCON2 register.
movwf NVMCON2
bsf NVMCON1, WR ; Set WR bit to begin WRITE/ERASE.
bsf INTCON, GIE ; Re-enable Interrupts.
WRITEwater
btfsc NVMCON1, WR ; WRITE finished?
goto WRITEwater ; No. Loop.
goto MainProgram ; Yes.

Ask yourself; do you need to wait for write finished before returning?
Might you instead code that wait before the next write?

[James Wages]

James C., thank you for your 2 replies but your 2nd reply (see quoted excerpt below) indicates you misread a register name. You suggested I write F0h to NVMDATH, but NVMDATH is a "data" register. The reality is that F0h must be written to NVMADRH, the address register. So the question I originally posted about the "data" register NVMDATH:NVMDATL remains...


"If truly only '8-bit' then why is the NVMDATH:NVMDATL register pair (16-bits) required to WRITE to EEPROM? In other words, if truly 8-bit, am I allowed to WRITE to only to the Low Byte, NVMDATL?"


Would you say that NVMDATH is ignored on the 16F18854? Because the datasheet is so unclear, such can only be an assumption -- an assumption based on the datasheet's "8-bit" wording being correct. Or should I write 0 to NVMDATH just to be safe? (That too "assumes" that a 0 in that register would avoid trouble.)


I opened a case ticket with Microchip last week and they finally replied today (it always takes them a long time to reply). They said they would confirm my error report and then add changes to the next datasheet revision. But who knows when that will be.

Programming and then testing and finding one's code seemingly works without problem is all fine and well, but having a clear portion of the MCU's datasheet to justify one's code is also important. That's what frustrates me about the current Revision B datasheet.

--James Wages



Fri, 4 Aug 2017 14:53:30 +1000, James Cameron <***@laptop.org>:

Because the NVM peripheral accesses more than the EEPROM, and there
must be a way to disambiguate that access.

Because the address decoder described by Table 10-2 NRM ORGANIZATION
says that access to EEPROM requires an NVMDATH value of F0h.

Post by James Wages
In other words, if truly 8-bit, am I allowed to WRITE to only to the
Low Byte, NVMDATL?

Provided you have written F0h to NVMDATH, probably yes.

Should any code write a different value to NVMDATH, no.

[James Cameron]

G'day James,

NVMDATH is required to exist in the IP because the NVM peripheral
accesses more than the EEPROM, and there must be a way to support more
than 8-bit access for the NVM address spaces that require it.

Since the NVM address space for EEPROM is specified for 8-bit cells,
NVMDATH is probably not required to be set to any specific value, but
the examples do so.

I do not think it is correct to look for datasheet support for every
action a program performs or avoids. The datasheet is an abstraction
of the silicon IP. If you need provable correctness, you should be
negotiating and paying for access to the IP. In my opinion. ;-)

Post by James Wages
James C., thank you for your 2 replies but your 2nd reply (see quoted excerpt below) indicates you misread a register name. You suggested I write F0h to NVMDATH, but NVMDATH is a "data" register. The reality is that F0h must be written to NVMADRH, the address register. So the question I originally posted about the "data" register NVMDATH:NVMDATL remains...
"If truly only '8-bit' then why is the NVMDATH:NVMDATL register pair (16-bits) required to WRITE to EEPROM? In other words, if truly 8-bit, am I allowed to WRITE to only to the Low Byte, NVMDATL?"
Would you say that NVMDATH is ignored on the 16F18854? Because the datasheet is so unclear, such can only be an assumption -- an assumption based on the datasheet's "8-bit" wording being correct. Or should I write 0 to NVMDATH just to be safe? (That too "assumes" that a 0 in that register would avoid trouble.)
I opened a case ticket with Microchip last week and they finally replied today (it always takes them a long time to reply). They said they would confirm my error report and then add changes to the next datasheet revision. But who knows when that will be.
Programming and then testing and finding one's code seemingly works without problem is all fine and well, but having a clear portion of the MCU's datasheet to justify one's code is also important. That's what frustrates me about the current Revision B datasheet.
--James Wages
Because the NVM peripheral accesses more than the EEPROM, and there
must be a way to disambiguate that access.
Because the address decoder described by Table 10-2 NRM ORGANIZATION
says that access to EEPROM requires an NVMDATH value of F0h.

Post by James Wages
In other words, if truly 8-bit, am I allowed to WRITE to only to the
Low Byte, NVMDATL?

Provided you have written F0h to NVMDATH, probably yes.
Should any code write a different value to NVMDATH, no.
--
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

[a***@stfc.ac.uk]

I do not think it is correct to look for datasheet support for every action a
program performs or avoids. The datasheet is an abstraction of the silicon IP.
If you need provable correctness, you should be negotiating and paying for
access to the IP. In my opinion. ;-)

Well, certainly hammering at the local FAE to find out the relevant information ...