Searching \ for '[PIC] 16F18854 WRITE to EEPROM in Assembly' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/memory.htm?key=eeprom
Search entire site for: '16F18854 WRITE to EEPROM in Assembly'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] 16F18854 WRITE to EEPROM in Assembly'
2017\08\04@002147 by James Wages

flavicon
face
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



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

2017\08\04@005337 by James Cameron

flavicon
face
On Fri, Aug 04, 2017 at 01:21:40PM +0900, James Wages wrote:
> 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:
>
> 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.

> 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.

> 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.

{Quote hidden}

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

>     movlw   0x55                ; Put 55h into NVMCON2 register.
>     movwf   NVMCON2            
Trailing spaces are awful.  ;-)

>     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 Cameron
http://quozl.netrek.org/
-- http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
mailman.mit.edu/mailman/listinfo/piclist
.

2017\08\07@005452 by James Wages

flavicon
face
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 <spam_OUTquozlTakeThisOuTspamlaptop.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.
       >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
mailman.mit.edu/mailman/listinfo/piclist
.

2017\08\07@011749 by James Cameron

flavicon
face
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.  ;-)

On Mon, Aug 07, 2017 at 01:54:44PM +0900, James Wages wrote:
{Quote hidden}

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

2017\08\07@054858 by alan.b.pearce

face picon face
> 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 ...



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

More... (looser matching)
- Last day of these posts
- In 2017 , 2018 only
- Today
- New search...