CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Store / recall some runtime values in 16F1574?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
starfire151



Joined: 01 Apr 2007
Posts: 195

View user's profile Send private message

Store / recall some runtime values in 16F1574?
PostPosted: Sat Feb 20, 2021 3:14 pm     Reply with quote

Is there a way to store a few bytes of runtime values in the PIC16(L)F1574 chip and restore them on the next power-up?

In looking at the datasheet for the 16F1574, it says it has "128 bytes if nonvolatile data storage" (not "of", "if"... it's probably a type-o but it's written the same way on the datasheet for the PIC12(L)F1572 chip, also Very Happy ).

Trying the write_eeprom() and read_eeprom() didn't work. Apparently this does not access like EEPROM. I looked a bit at the write_bank() and read_bank() commands but I'm not quite sure this would be appropriate or would work.

Does anyone have any ideas how I could save a few bytes (less than a dozen) in a non-volatile way using this chip?

Thanks.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sat Feb 20, 2021 3:29 pm     Reply with quote

Curious, so I downloaded the datasheet...

Chapter 10 of the datasheet tells how, shows using ASM...

Someone may have done it in 'C' though....
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 4:16 am     Reply with quote

This is the high endurance flash.
It is read/written using the program memory instructions, not the EEPROM
instructions. It doesn't behave like EEPROM at all, requiring a whole 'page'
to be erased, rather than a single byte. The page is 32 instructions long.
Remember that each 'word' of this can just store 14bits of data.
So it is nastily complex to use. The high endurance ability only applies to
the low byte in each word. You have to format your data to fit into
these reduced size words, and write the whole entity as a block.
Code:

#define HEF_LOCATION 0xF80 //change to suit chip

//Now start by 'preloading' the HEF, with the bytes you want. Bytes
//remember.
#ROM HEF_LOCATION = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,
18,19,20,21,22,23,24,25,26,27,28,19,30,31,32}
//Because we do this, the compiler won't put other values here, so
//we must fill with 32 values, from each of which a byte is actually
//used.  Change the low bytes to be what you actually 'want' stored
//here when the chip is first programmed.

void read_data_HEF(char * data, int size)
{

    //read a block from the HEF, and transfer alternate bytes
    //to a block in RAM
    char buffer[64]; //block size of HEF
    read_program_memory(HEF_LOCATION, buffer, 64);
    //Now move alternate bytes into RAM
    for (ctr=0;ctr<size;ctr++)
       *(data+ctr)=*(buffer+(ctr*2));
}

void write_data_HEF(char * data, int size)
{
    int ctr;
    //now write a block to the HEF
    char buffer[64]; //block size
    //Now copy the bytes required into this
    for (ctr=0;ctr<size;ctr++)
       *(buffer+(ctr*2))=*(data+ctr);
    //Now write this. Remember processor will stop during this write.
    write_program_memory(HEF_LOCATION, buffer, 64);
}

//So in your main, if you have your data to save stored as a structure
void main(void)
{
   struct {
       int16 something;
       int32 something_else;
       char some_text[8];
   } data_to_save;

   read_data_HEF(&data_to_save,  sizeof(data_to_save));
   //loads the data - first time the pre-saved values.

   //then when you want to write the structure:
   write_data_HEF(&data_to_save,  sizeof(data_to_save));
}
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 5:36 am     Reply with quote

As Mr. T. pointed out HEF is, well, 'interesting' ! Almost looks like someone created it by accident in the lab and someone else said 'better use it, it cost us a million bucks '...similar to 'sticky note glue'.
There's probably a 1009 PICs with similar features to the 1574, a few will have EEP for 'default' or 'runtime' values. Perhaps choose one of them ?
Since I always seem to need a RTC, I use a module that has a DS3231 AND a small EEP(4kb).Only cost $2 and save a lot of time....no pun intended. You can even use the SRAM in a DS1307 as it's battery backed !

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 7:29 am     Reply with quote

The thing that really 'annoys' about the HEF, is it tends to be supplied on
chips that often don't have a lot of spare RAM, and having to setup a whole
page of memory as a buffer to talk to this is very irritating. Sad
starfire151



Joined: 01 Apr 2007
Posts: 195

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 9:59 am     Reply with quote

Thanks, very much, for the replies.

I did some more digging and found an app note written by Microchip on how to access the High-Endurance Flash (AN1673, "Using the PIC16F1XXX High-Endurance Flash (HEF) Block"). It's dated 2014 but does directly relate to how to read and write from HEF. It even includes some C routines.

The note mentions the HEF as a cheaper alternative to EEPROM with the same retention features (100K E/W cycles) as opposed to Program Flash access, which is slated as 10K E/R cycles.

It's interesting to note that the read accesses can happen with no appreciable effect on the processor, the write cycles cause the processor to "stall", which includes responses to interrupts. It appears the stall period is around 2ms (from the code example) so it may not have that big an impact but still needs to be accounted for.

Mr. T, your example seems to be much more straight forward. In my specific case, I don't have that many values to save (3 16-bit values and 3 8-bit values) so this looks like a viable approach. I will try it out this morning.

I'm really trying to keep the footprint to a minimum for my application and the pins are all pretty well allocated. Ordinarily I'd just use a small 24LC16 I2C EEPROM but I don't have two pins for I2C.

This should be a good test case for the HEF anyway... Very Happy

Thanks, again, for all your help.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 10:14 am     Reply with quote

re:
Quote:
trying to keep the footprint to a minimum

That can come at a HUGE cost in required R&D time and money in getting 'something' (HEF in this case ) to work very reliably.

As the saying 'penny wise, pound foolish' goes, I've found using a 'big,expensive' PIC can save a lot of time, hence money.
You've probably spent at least 10 hrs reseaching this, still will need another 10 to get 'something' to work, another 10 to be sure it works.... that's 30hrs x $50/hr = $1500. THAT buys a lot of 'bigger-better' PICs.!!
I'm amazed very few factor in R&D as an actuual cost...
Just food for thought...
Jay
starfire151



Joined: 01 Apr 2007
Posts: 195

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 11:32 am     Reply with quote

Your point is well taken but isn't it also important to know how to work with the available features (as odd as they sometime are).

I'm not putting this project together to make thousands of end devices. I don't consider it "foolish" to delve into the odd features of a part. Since I'm retired now, my time is "infinitely" more valuable than $50/hour (which I was making substantially more than before I did retire Very Happy ). I just want to know how to make it tick...

I agree with your statement for those in a working, production atmosphere but if we don't spend a little time on R&D, we may as well resign ourselves to the fact that pretty soon all the datasheets will be in a foreign language... Rolling Eyes

Thanks, again, for the help.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 11:58 am     Reply with quote

Key is, that I'm 'taking advantage' of the supplied CCS function, that
automatically erases a page provided you start on a page boundary
(which the HEF does). Hopefully I got the code right (these were
written 'as I typed', so could easily have faults (though reading again,
they still look right). Smile
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Sun Feb 21, 2021 12:03 pm     Reply with quote

Seeing how you have lots of 'free' time, if you want to have a lot of 'fun'..figure out HOW to detect and correct for a broken wire in a system using Dallas Semi 'one-wire' temperature sensors ! Rolling Eyes

It's my current 'brain teaser' while waiting for Spring to arrive

Sad thing is I can currently 'detect and correct' a system using 15 miles of copper wire, so you'd think a mere 100' would be easy.

Jay
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Feb 22, 2021 4:36 am     Reply with quote

I'd suggest probably reading the device ID. If I remember correctly the
last byte is a family number that is the same for all the devices. So if this
doesn't retrieve correctly, you are not talking to the device properly,
and know there is a problem.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group