HEF usage: One suggestion and one question

[pinhe...@gmail.com]

Hi all,

I am starting a new project using a PIC16F1705.

I willl use the "pic_data_hef" library.

This libray requires the definition of a constant containing the start address of the HEF, and named HEF_ADDRESS_OFFSET.

For the 16F1705, that value is 0x1F80

My suggestion: Couldn't that constant be defined in the device include file, so that, if I decide to port my code to another PIC, the value of the constant would be automatically updated, and thus, avoiding possible errors ?

In my application, the user will be able to select a "mode".    I would like that the selected mode be written in the HEF, so that at the next boot, the last selected mode is automatically picked up.   

At the very first usage, there will also be a default mode defined

(I am simplifying here, because in fact there is not only one byte to save in HEF but several data, but let's keep the question simple)

My question is: How can I define those default values in HEF for the very first start of the application ?    For example, how can I force the value "0x15" in location 0x1F80 which is the adress of the first HEF location during programming time ?

Thanks all for your help

David

[Rob CJ]

Hi David,

Device files are generated from the XML files that Microchip provides. As far as I can see this offset value is not present in these xml files so it cannot be automatically generated.

About your second question. I am not aware that a PIC programmer can program the HEF locations. By default (after erase) the data is always 0xFF.

So what I do I check if the value of a certain address is 0xFF and if that should be something else then I know the HEF is not initialzed. I then write a valid value other than 0xFF to that location and also store other values in the HEF that I need. The next time I power up the device I see this is a valid value and know that the other values in the HEF are valid so I do not touch them. So you need to define some HEF location that you use as an 'I am initialized' location.

I have used this in my project where I built a power supply with preset buttons of which the values where stored in HEF. This project btw lead to the HEF library 🙂.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens pinhe...@gmail.com <pinhe...@gmail.com>
Verzonden: zaterdag 22 oktober 2022 00:31
Aan: jallib <jal...@googlegroups.com>
Onderwerp: [jallib] HEF usage: One suggestion and one question

 

--
You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/4de5fe02-087b-4db1-9d4c-2d4e8b44dab8n%40googlegroups.com.

[evan....@googlemail.com]

HEF is essentially a specific type of memory at specific locations.  The HEF is only one byte of each work ( a common mistake is to assume HEF is the word within the HEF range).

So, the size of the HEF range.  This can be extracted from other sources like the PICkitPlus database ( we have collated the data required ).  

From a pre-loading the HEF range you can treated the HEF memory as self-write progmem or you could .ORG you data into the correct location.

From a programming point of view.  PICKitPlus protects HEF (and SAF) in terms of caching prior to programming the chip and restoring the appropriate memory range.

 Hope this helps.

[Rob Hamerling]

Hi David,

On 22/10/2022 00.31, pinhe...@gmail.com wrote:

I am starting a new project using a PIC16F1705.

I willl use the "pic_data_hef" library.

This libray requires the definition of a constant containing the start address of the HEF, and named HEF_ADDRESS_OFFSET.

For the 16F1705, that value is 0x1F80

My suggestion: Couldn't that constant be defined in the device include file, so that, if I decide to port my code to another PIC, the value of the constant would be automatically updated, and thus, avoiding possible errors ?

Maybe there is a method to determine the HEF offset.
Assuming:
- HEF is always 128 words
- HEF is last part of program memory
HEF-offset = amount of program memory less 128

Regards, Rob.

--
Rob Hamerling, Vianen, NL

[Evan Venn]

What me to check it is ways 128?

Get Outlook for Android

---

From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of Rob Hamerling <robham...@gmail.com>
Sent: Saturday, October 22, 2022 7:19:17 PM
To: jal...@googlegroups.com <jal...@googlegroups.com>
Subject: Re: [jallib] HEF usage: One suggestion and one question

 

--

You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/eaf6a66d-0ff1-f9a9-1e8d-5d217f3ef37f%40gmail.com.

[Rob CJ]

Hi Rob,

I checked the Jallib sample files that I created for testing the HEF library and it seems you are right but I am not sure if that will be the case for the future.

The example below is for a 2k PIC (16F1507) sample file. You you take the ROM size and substract 128 bytes.

-- High Endurance Flash (HEF) address declarations.

const HEF_NR_OF_BYTES    = 128

const HEF_ADDRESS_OFFSET = 2048 - HEF_NR_OF_BYTES

include pic_data_hef

In the device file of this PIC you find:

pragma  code             2048

To make life easier you could extend all device files with something like (for this PIC as example):

const ROMSIZE = 2048 

And then it becomes:

const HEF_ADDRESS_OFFSET = ROMSIZE - HEF_NR_OF_BYTES

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens Rob Hamerling <robham...@gmail.com>
Verzonden: zaterdag 22 oktober 2022 20:19
Aan: jal...@googlegroups.com <jal...@googlegroups.com>
Onderwerp: Re: [jallib] HEF usage: One suggestion and one question

 

--

[Rob Hamerling]

Hi RobJ and others,

My assumption that HEF-size is always 128 comes from:

https://ww1.microchip.com/downloads/en/DeviceDoc/30010068G.pdf

In the explanation colums it says:

HEF: High–Endurance Flash 128B Non–volatile data storage with high–endurance 100k E/W cycles

It doesn't say if it is always in the highest program address region.
Searching all datasheets isn't the favorite aspect of my hobby....

As far as size of program memory concerns: the device file contain a "pragma code", but I cannot find in the docs if there is a companion built-in constant definition, for example like there is one for bank size: "CONST target_bank_size = cexpr".  
If such a constant doesn't exists yet it would be handy to add it to the compiler.

Regards, RobH

[pinhe...@gmail.com]

Thanks all for those creative answers

@Rob : Indeed, using one HEF location as an indicator to know if the settings have already been initialised or not was my fallback solution.   As you explain (and I wasn't aware of that), if you do not receive the value in the XML from Microchip, you can not put that value in the include file....  unfortunately.

About the discussion to deduce the offset by assuming the HEF size is always 128 bytes, that seems very risky to me.   Furthermore, in the document Rob H linked, there are already a bunch of PIC's for which that size is not at all 128 bytes.....

I do not know what data is included in the Microchip XML files, but how does the programmers (ICD, PicKit, ....)  know how much HEF there is ?   Or do they not at all make the difference between normal flash and HEF ?   Seems weird to me (but I'm not an expert)....

Enjoy your Sunday

Daiv

[Evan Venn]

We asked Microchip for the information.  We are Microchip Approved Software Partners so we can ask for key information. 

This information was the used to populate the PIckit parts database.

------

Get Outlook for Android

---

From: jal...@googlegroups.com <jal...@googlegroups.com> on behalf of pinhe...@gmail.com <pinhe...@gmail.com>
Sent: Sunday, October 23, 2022 3:35:36 PM
To: jallib <jal...@googlegroups.com>
Subject: Re: [jallib] HEF usage: One suggestion and one question

 

--

You received this message because you are subscribed to the Google Groups "jallib" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jallib+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/61cdd53e-398c-4c2d-8786-2762984b7e3an%40googlegroups.com.

[pinhe...@gmail.com]

Just another thought:  

In the device include file of older PIC's with dedicated eeprom, I see  a directive defining that eeprom, by adress and size.

For example, for a 16F628A :

pragma  eeprom           0x2100,256

Is this the kind of info you retrieve from the XML files ?
For my information, where could I see the content of such a XML file (say the one for the 16F1705 I use) ?

[Rob CJ]

Hi David,

The XML files are provided by Mircochip if you download MPLABX.

If we would want to use the ROM code size (which is known from the XML) it woule be possible to add something like this to the compiler functionality:

      target_code_size 

So in your program you would have something like:

const HEF_OFFSET_ADDRESS = target_code_size - HEF_NR_OF_BYTES (or just minus 128).

I attached the XML for your PIC.

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens pinhe...@gmail.com <pinhe...@gmail.com>
Verzonden: zondag 23 oktober 2022 16:48
Aan: jallib <jal...@googlegroups.com>
Onderwerp: Re: [jallib] HEF usage: One suggestion and one question

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/02a30931-3dbe-4249-a3b2-4dcfe77aa78cn%40googlegroups.com.

[pinhe...@gmail.com]

Hi,

Thanks Rob.

I had a look in the 16F1705.pic file, and indeed, it seems impossible to calculate the exact offset for the start of the HEF area.....

Anyway, thanks for the info: I learned a lot !

Kind regards,

David

[Rob CJ]

Hi David,

An option would still be to add a constant to all device files with the name ROMSIZE but I do not see any other application (yet) than using it for determining the offset address for the HEF. 

It would make your program al little bit easier to port to another PIC with different ROM size.

Maybe there are other applications for this ROMSIZE constant, so if anybody knows ....

Kind regards,

Rob

---

Van: jal...@googlegroups.com <jal...@googlegroups.com> namens pinhe...@gmail.com <pinhe...@gmail.com>

Verzonden: dinsdag 1 november 2022 17:47

To view this discussion on the web visit https://groups.google.com/d/msgid/jallib/c55d7e89-c153-4847-a0f4-7d51669bc9afn%40googlegroups.com.