18F87J93 _eeprom=0?

General discussion relating to the library modules supplied with the compiler

Moderators: David Barker, Jerry Messina

Post Reply
tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

18F87J93 _eeprom=0?

Post by tcdev » Fri Jan 23, 2015 5:00 am

From the datasheet:

"Flash Program Memory has Word Write Capability for Data EEPROM Emulators"

I would have assumed this meant it had support for the Swordfish EEPROM library!?! Am I wrong? Is this a bug?

tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

Re: 18F87J93 _eeprom=0?

Post by tcdev » Fri Jan 23, 2015 5:26 am

And to have a stab at answering my own question...

Looking at the 18F87J90 Family Datasheet and the EEPROM.bas code, it looks like the device will support EEPROM, but the library is not compatible with this device.

Amongst other differences, the 87J90 appears to require erasing of pages (64 bytes) before word writes.

Is this a fair call? Anyone written routines for this device? Or am I writing my own?

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: 18F87J93 _eeprom=0?

Post by David Barker » Fri Jan 23, 2015 9:48 am

> I would have assumed this meant it had support for the Swordfish EEPROM
> library!?! Am I wrong? Is this a bug?

Yes, you are wrong. EEPROM <> HEF - so it would be unfair to expect the EEPROM library to perform a function it was not designed to do. It is certainly not a bug. High Endurance Flash (HEF) sits at the top of normal program flash - I expect it's microchips way of keeping die costs down by replacing dedicated EEPROM. An absolute must read is this document

http://ww1.microchip.com/downloads/en/A ... 01673A.pdf

It even has some "C" code which you could port over. As with program FLASH, the normal sequence to write a word to memory is

(1) read single row into RAM
(2) write new word into RAM row at position <address>
(3) Erase device row
(4) write RAM row to device row

it's pretty straight forward, just requires more work than EEPROM. If you are uncomfortable with the concept, there are plenty of 18F devices with authentic EEPROM - use one of them instead for your design - or use an external EEPROM chip.

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: 18F87J93 _eeprom=0?

Post by Jerry Messina » Fri Jan 23, 2015 10:51 am

There's also AN1095 Emulating Data EEPROM for PIC18 and PIC24 MCUs and dsPIC DSCs and the DEE emulation library (in C)
see http://www.microchip.com/wwwAppNotes/Ap ... e=en530593

"Word Write Capability for Flash Program Memory for Data EEPROM Emulators" is a bit of marketing hype. While it's a true statement, pretty much ALL of the 18F chips have this capability.
Amongst other differences, the 87J90 appears to require erasing of pages (64 bytes) before word writes.
Having dealt with bootloaders for the J series, the J90 family actually makes it harder to deal with than many other devices since it has an erase block size of 1K bytes.
While you can write 64 bytes at a time, you have to erase a rather large block. That means you would have to have an additional spare 1K page that you could copy the data to while you do the erase/edit or have a large 1K ram buffer.

User avatar
David Barker
Swordfish Developer
Posts: 1214
Joined: Tue Oct 03, 2006 7:01 pm
Location: Saltburn by the Sea, UK
Contact:

Re: 18F87J93 _eeprom=0?

Post by David Barker » Fri Jan 23, 2015 11:21 am

> is a bit of marketing hype.

Absolutely!

> That means you would have to have an additional spare 1K page that you
> could copy the data to while you do the erase/edit or have a large 1K ram buffer.

In that case, declare the read array inside your write function as local (not at the module level). This will ensure the RAM gets recycled.

tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

Re: 18F87J93 _eeprom=0?

Post by tcdev » Fri Jan 23, 2015 11:56 am

David Barker wrote:it's pretty straight forward, just requires more work than EEPROM. If you are uncomfortable with the concept, there are plenty of 18F devices with authentic EEPROM - use one of them instead for your design - or use an external EEPROM chip.
Not uncomfortable with the concept at all, just disappointed that the J90 is not compatible with the Swordfish EEPROM module. :cry: I got excited last week when I saw that the J90 supported EEPROM and that Swordfish had an EEPROM module... I thought it was going to be a doddle. :mrgreen:

I've inherited an existing (unfinished) design that is actually in production! :shock: So no luxury of changing the device for me! The original developer decided that touch screen calibration was either unnecessary or (more likely) too difficult. No surprise then that the end users have complained that the screen input 'doesn't work'. FTR I discovered - only today - that the code was ripped (uncredited) from the Wiki touch screen article/example, minus the calibration code.

We've modified (patched) the circuit for the resistive touch from 4-wire to 2-wire (reducing the ADC channels required to 2) and I've moved the ADC sampling into an ISR using CCP2/Timer1. It's not the first touch screen driver I've done, so I'll be implementing the same 3-point calibration algorithm I've used before. Of course I need somewhere to store the calibration values, hence the EEPROM. Not a great drama as I've got oodles of free programming flash and I'll only be writing a single chunk at any time, and rarely at that, so I can get away with a rather brain-dead implementation. On this subject - is there any doco/map file I can see to decide where my EEPROM should reside, or am I reduced to looking at the .hex file? eg. Is end-of-flash safe?

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: 18F87J93 _eeprom=0?

Post by Jerry Messina » Fri Jan 23, 2015 1:10 pm

just disappointed that the J90 is not compatible with the Swordfish EEPROM module
It's a drag that the J90 doesn't HAVE eeprom. None of the J series do. Microchip makes it sound like it's no big deal, but using flash for EEPROM isn't the same ballgame.

The easiest thing is probably to place your "EEPROM" space at the top of memory. That way you can change the SF '_maxrom' setting so that it will always reserve that page. However, the config words for the J90 are kept in the last few bytes of the last page @ 0x1FFF8 (erase block 0x1FC00). Since you don't want to ever erase that page (or you chance bricking the device), I'd skip down to the next 1K block and reserve that one (0x1F800-0x1FBFF).

Then set

Code: Select all

#variable _maxrom = $01F800            // 126 KB of program ROM
and that will keep SF from allocating code to that space

tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

Re: 18F87J93 _eeprom=0?

Post by tcdev » Tue Jan 27, 2015 2:11 am

Jerry Messina wrote:The easiest thing is probably to place your "EEPROM" space at the top of memory. That way you can change the SF '_maxrom' setting so that it will always reserve that page. However, the config words for the J90 are kept in the last few bytes of the last page @ 0x1FFF8 (erase block 0x1FC00). Since you don't want to ever erase that page (or you chance bricking the device), I'd skip down to the next 1K block and reserve that one (0x1F800-0x1FBFF).

Then set

Code: Select all

#variable _maxrom = $01F800            // 126 KB of program ROM
and that will keep SF from allocating code to that space
Awesome - thanks!

tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

Re: 18F87J93 _eeprom=0?

Post by tcdev » Tue Jan 27, 2015 12:00 pm

And to provide closure on this one as well...

I've implemented my EEPROM read/write routines and it appears to work well. All based on the Microchip-supplied PIC18F EEPROM emulation code written in C, albeit much more fundamental as I expect to be writing the EEPROM only a handful of times through its lifetime.

The only gotcha for me was the note in the little shaded box at the bottom of page 95, regarding the value of TBLPTR prior to EECON1.WR being set. Left me scratching my head for an hour or so and I must admit the requirement still seems peculiar to me but, it is evidently quite important! :shock:

Jerry Messina
Swordfish Developer
Posts: 1469
Joined: Fri Jan 30, 2009 6:27 pm
Location: US

Re: 18F87J93 _eeprom=0?

Post by Jerry Messina » Tue Jan 27, 2015 1:27 pm

... and I must admit the requirement still seems peculiar to me but, it is evidently quite important!
Here's the datasheet note:
Before setting the WR bit, the Table Pointer address needs to be within the intended address range of the 64 bytes in the holding register.
I think that comes from that fact (as the note says) that in order to update a 64-byte page, the TBLPTR has to be pointing to the page you want to update. Makes sense so far.
But, if you've used auto-increment instructions to load the page there's a good chance you'll be pointing to the NEXT page, hence the note.

Anyway, glad you've got it working!

tcdev
Posts: 15
Joined: Thu Jan 15, 2015 12:31 am

Re: 18F87J93 _eeprom=0?

Post by tcdev » Tue Jan 27, 2015 11:49 pm

Jerry Messina wrote:
... and I must admit the requirement still seems peculiar to me but, it is evidently quite important!
Here's the datasheet note:
Before setting the WR bit, the Table Pointer address needs to be within the intended address range of the 64 bytes in the holding register.
I think that comes from that fact (as the note says) that in order to update a 64-byte page, the TBLPTR has to be pointing to the page you want to update. Makes sense so far.
But, if you've used auto-increment instructions to load the page there's a good chance you'll be pointing to the NEXT page, hence the note.

Anyway, glad you've got it working!
That would certainly make sense for 64 byte writes (which is what I do now), but initially I was trying to get 2-byte writes to work and had the same issue when TBLPTR was pointing to the 3rd byte in the table/page... still trying to wrap my head around what they could possibly be doing in silicon/microcode for that to matter... :shock: in fact I would have expected 3 bytes to be written instead of 2, but nothing got written!

Anyway, all sorted now. FTR using auto pre-increment instead of post-increment.

TonyR
Posts: 75
Joined: Fri Jan 14, 2011 11:49 pm
Location: Sydney
Contact:

Re: 18F87J93 _eeprom=0?

Post by TonyR » Sun Sep 13, 2015 1:34 am

What a pity you guys had to go through all that. Moral is request help sooner!

In Dec 2014 I wrote an SF module for an automated GLCD touch screen calibrator running on 18F87J93 with stored non volatile calibration values. It was implemented by setting a DIP switch which would make the J93 go to "cal" mode. In the end the customer never used it because at the time they were in haste and wanted product out the door!

Post Reply