Page 1 of 1
18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 5:00 am
by tcdev
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?
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 5:26 am
by tcdev
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?
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 9:48 am
by David Barker
> 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.
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 10:51 am
by Jerry Messina
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.
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 11:21 am
by David Barker
> 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.
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 11:56 am
by tcdev
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.
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.
I've inherited an existing (unfinished) design that is actually in production!
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?
Re: 18F87J93 _eeprom=0?
Posted: Fri Jan 23, 2015 1:10 pm
by Jerry Messina
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
Re: 18F87J93 _eeprom=0?
Posted: Tue Jan 27, 2015 2:11 am
by tcdev
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!
Re: 18F87J93 _eeprom=0?
Posted: Tue Jan 27, 2015 12:00 pm
by tcdev
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!
Re: 18F87J93 _eeprom=0?
Posted: Tue Jan 27, 2015 1:27 pm
by Jerry Messina
... 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!
Re: 18F87J93 _eeprom=0?
Posted: Tue Jan 27, 2015 11:49 pm
by tcdev
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...
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.
Re: 18F87J93 _eeprom=0?
Posted: Sun Sep 13, 2015 1:34 am
by TonyR
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!