PIC16F1619 High Endurance FLASH access

[Ground_Loop]

I have a project that utilizes a PIC16F1619 uC.  I need the ability to save data that will survive a power loss.  The project controls and monitors a testing process that will run continuously for several months.  On other PIC models I just use EEPROM.  This series does not have EEPROM, but instead uses what they call High Endurance FLASH memory.  The data sheet does not have this memory section identified in the very crude memory map, that I can find anyway.  So my question is:  Where is this memory and how is it accessed via C-programming?  And no I can't change to a different flavor uC.

[ggchab]

This is flash program memory that you can use to save data.
Look at section 10 of the datasheet: "The Flash program memory is readable and writable during normal operation over the full VDD range"
The section details the procedures and registers to use it 

(Of course, the memory allocated to the data cannot be used by the application)

[SiliconWizard]

Reading the specs of the PIC16F1619, what they call High Endurance Flash Memory (HEF) is actually separate from the main Flash memory (which is itself user-writable and could also be used to store user data, but doesn't have as much endurance.)

The HEF memory of this PIC is tiny (128 bytes).

Dunno if you have read the datasheet carefully or not. Endurance of both regular Flash and HEF is stated:
(see TABLE 35-5: MEMORY PROGRAMMING SPECIFICATIONS) https://www.microchip.com/wwwproducts/en/PIC16F1619

Program Flash Memory: Cell Endurance: 8K words, min. 10k erase/write cycles
HEF (High-Endurance Flash Cell) : 128 bytes, min. 100k erase/write cycles

So to sum it up: the HEF memory is a separate memory block, it's small (128 bytes only), and has a minimum number of write cycles ten times higher than program flash.
It's still in the order of ten times lower than regular EEPROM which is usually more like 1 million cycles minimum or more. Write times may also be longer than with EEPROM (TBC).

So are you losing anything compared to EEPROM: short story: yes. But it's cheaper. Power consumption may be lower too (TBC as well).

[mikerj]

The data sheet does not have this memory section identified in the very crude memory map, that I can find anyway.

Look at section 3.2 (Page 21) of the datasheet.  Address range of the high endurance flash is 1F80h-1FFFh.

The HEF memory of this PIC is tiny (128 bytes).

As per usual the Microchip datasheet is quite contradictory.  128 bytes is mentioned in multiple places throughout the datasheet, including the headines and memory map above, but Table 1 (Page 3) of the datasheet suggests the 16F1619 has 1024 bytes of HEF.  I have no idea if that correct or not.

[Ground_Loop]

Hey thanks all.  Stupid me, I was looking in section 10 'Flash Program Memory Control' for the location.  I was hoping for a function library to make my life a bit easier, but it looks like I may be playing with registers directly.

[SiliconWizard]

As per usual the Microchip datasheet is quite contradictory.  128 bytes is mentioned in multiple places throughout the datasheet, including the headines and memory map above, but Table 1 (Page 3) of the datasheet suggests the 16F1619 has 1024 bytes of HEF.  I have no idea if that correct or not.

I don't know either. And yes that is usual in all those Microchip datasheets that cover a whole family...
Problem is, if the 1024 figure is indeed right, what is the corresponding memory map? We could assume that since the last program memory address is 1FFFh and that the HEF section is at the end of this, that the start address of HEF for the 16F1619 would then be 1C00h - 1FFFh ... even the fact that they mix both program flash and HEF in the same table and same address area is a bit confusing.

I haven't seen any clarification on this in the "PIC16(L)F1615/1619 Family Errata and Data Sheet Clarification" document either, in which we could expect it.

To get more info, I had to resort to reading the following app note (something also usual with Microchip):
https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en567894

Unfortunately, this app note doesn't talk about more than 128 bytes either. Dang Microchip!!

[ggchab]

I don't know if it's possible in your project, how many bytes you have to write and how critical they are, but you could also detect power loss and save data in that case only.

[JPortici]

It's 128 bytes.
In any case, HEF is just flash. It has to be treated as such (erase row, program row) and will try to execute if control reaches that address.
It's only in the newest 8bit devices that the developer has the option to enable the "storage area flash" partition and inhibit accidental code execution in that area

[Ground_Loop]

I don't know if it's possible in your project, how many bytes you have to write and how critical they are, but you could also detect power loss and save data in that case only.

I don't need much:  Start date and time, current/end cycle counts, and current/end date and time.  I will update current date and time along with counts about every hour.  The machine actually cycles about once a minute.  Should be about 16,000 updates.

[lucazader]

You could look at doing a crude form of wear leveling on the cycles count (since this is the one that is updated relatively regularly) if you are concerend about the write cycles of the flash.

Could be as simple as having 10 cycle count storage areas, and each time you update the value you just loop round the 10 values, look for the highest stored counts, and save to the next one in the array.

[Ground_Loop]

You could look at doing a crude form of wear leveling on the cycles count (since this is the one that is updated relatively regularly) if you are concerend about the write cycles of the flash.

Could be as simple as having 10 cycle count storage areas, and each time you update the value you just loop round the 10 values, look for the highest stored counts, and save to the next one in the array.

Good suggestion, I'll give that some thought.

Turns out that MCC has a memory resource with FLASH management functions.  So, looks like I'm good.  Thanks all for the help.

[dmendesf]

There's another thing to remember: program memory is 14 bits wide for this device but HEF comprises only the 8 lower bits.

[ggchab]

And the block size of the HEF seems to be the same as the rest of the program memory: 32 words. This means 4 blocks of HEF only. This will reduce the effect of wear leveling if your data block is, let say, around 10 bytes: you'll have to use 32 bytes anyway 

[hli]

Maybe have a look at Microchips Data EERPROM Emulation library. It creates storage which can be used like EEPROM while using Flash memory, and includes some kind of wear leveling (it rotates through the available blocks of memory).

[jpanhalt]

There's another thing to remember: program memory is 14 bits wide for this device but HEF comprises only the 8 lower bits.

It's 14-bit memory.  You just have to use the right tools to access it, much like EEPROM.   One tool is the 16-bit FSRn.

[Ground_Loop]

I got it working.  Thanks again all.

[SiliconWizard]

I got it working.  Thanks again all.

Have you figured out the 1024 vs 128 bytes on the 1619 or have you not bothered so far?

I guess to get an answer you'll need to ask Microchip's support directly. You can first try on their forum.

[Ian.M]

There's another thing to remember: program memory is 14 bits wide for this device but HEF comprises only the 8 lower bits.

It's 14-bit memory.  You just have to use the right tools to access it, much like EEPROM.   One tool is the 16-bit FSRn.

Yes, but the high six bits of the HEF address range aren't HEF, so are only rated for 10K min. endurance.
See datasheet TABLE 35-5: MEMORY PROGRAMMING SPECIFICATIONS,

D125 EHEFC High-Endurance Flash Cell 100K — — E/W 0C  TA  +60°C, lower
byte last 128 addresses.

That means you MUST NOT use a RETLW table, as the high (op-code) bits will die before the data bits and execution could go off into La-La land or it could drop through to the next location when the op-code becomes corrupted.  Throw out your old 'classic' midrange table access code and replace it with INDF/FSR program memory access.

[Ground_Loop]

I got it working.  Thanks again all.

Have you figured out the 1024 vs 128 bytes on the 1619 or have you not bothered so far?

It's 128 words in 32 word blocks.

[Ground_Loop]

There's another thing to remember: program memory is 14 bits wide for this device but HEF comprises only the 8 lower bits.

It's 14-bit memory.  You just have to use the right tools to access it, much like EEPROM.   One tool is the 16-bit FSRn.

Yes, but the high six bits of the HEF address range aren't HEF, so are only rated for 10K min. endurance.
See datasheet TABLE 35-5: MEMORY PROGRAMMING SPECIFICATIONS,

D125 EHEFC High-Endurance Flash Cell 100K — — E/W 0C  TA  +60°C, lower
byte last 128 addresses.

That means you MUST NOT use a RETLW table, as the high (op-code) bits will die before the data bits and execution could go off into La-La land or it could drop through to the next location when the op-code becomes corrupted.  Throw out your old 'classic' midrange table access code and replace it with INDF/FSR program memory access.

I assume 10K writes is a guaranteed minimum.  I should be OK.  Nonetheless, I'm using 14 bits.

Have any of you seen memory locations 'worn out' from excessive writes?

[Ian.M]

IIRC some of the older dsPICs and PIC24s were only around 1K write endurance and it was quite possible to wear one out doing active development.  Otherwise, there have been quite a few reports of noobs trashing their EEPROM by writing buggy code that gets stuck in a write loop then leaving it powered for a few days.