I could not see any Great Cow BASIC documentation on whether the compiler excludes the High Endurance Flash memory from available program flash memory. There was nothing related in heflash.h. There was also nothing in the chipdata 16f1619.dat file indicating the start/end of HEF (1F80-1FFF).
Initially I thought I could use #option bootloader but I think the diagram in the help is misleading because it shows the bootloader at the top of memory, but the option actually reserves memory at the bottom of memory (eg the example #option bootloader 0x800 reserves program memory between 0x000 and 0x7FFF for the bootloader with the user program starting after that at 0x800).
So I assume that the HEF memory is not reserved, in which case is there any guarantee that the compiler will not trample over that memory?
(The Microchip xc8 compiler has the —ROM=default,-1f80-1fff compiler option to reserve the HEF memory.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As of right now, the only way I know of to preserve HEF memory is to program using the MPLABX IPE GUI application( MPLABX V5.05) The memory settings need to be changed so that the app is not allowed to auto detect memory . And a range to preserve must be entered, The settings shown in the attached screen hot work ok for 16F1619.
IPECMD is suposed to be able to preserve a memory range wth the -OP switch, but it does not work and neither does the -ON switch, These either generate an error or result in a programming failure.
Thanks for that William - but IPE is a whole other can of worms in my experience. I have two PICkit 3s and only one of them (mostly) works with IPE but is always a trial. That's why I signed up for the PICkitPlus software :)
In any event, I'm not sure whether the Great Cow BASIC compiler doesn't trample over that memory - for example, xc8 generally seems to throw ISRs to top of memory something which can be avoded by the compiler option to reserve memory ranges.
I think a more elegant solution is a compiler #option to reserve a memory range which may be useful not just for HEF memory range exclusions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Strategy. Have the compiler protect that region of memory, and, have PICKITPLUS handle the memory appropriately.
For the compiler we need to figure out how to add the memory regionto the .dat file. And, ensure the compiler handles the memory region.
For PICKITPlus we need to simply treat the HEF like EEPROM. We will need to add HEF memory region to the device database and then update the programmer software.
Sounds so easy. It is not.
I am discussing our strategy with Hugh.
Meanwhile.... William/Bill has good insights.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can someone please verify that HEF is NOT an explict memory region that cannot be erased?
PICKitPlus Programmers
If the HEF is part of any memory region then the standard programming approach WILL erase the HEF, because the 'Block Erase Program Memory' would included the HEF.
So, an ERASE in the PICKitPlus GUI or using /e with PKCMD+... would erase the HEF regardless
Is this understood as a constraint
PKCMD+
Assuming that we cannot protect the HEF memory region. PKCMD+ could be uploaded to READ/RESTORE & VERIFY during programming operations.
An accaptable solution?
PK+GUI
Depending on whether HEF is mutually exclusive to EEPROM then we can adapt the GUI software to support HEF. Actaully, not to hard change. But HEF MUST be mutually exclusive to EEPROM.
The EEPROM dialog could be adapted to support HEF - so, you unchecked the 'new' EEPROM/HEF then would READ/RESTORE and VERIFY HEF
A reasonalble approach?
What other thoughts?
Last edit: Anobium 2018-09-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The PIC16F1XXX family of general purpose Flash microcontrollers features the 8-bit PIC® MCU enhanced mid-range core. Carefully trading functionality versus cost, several members of this family, including the PIC16F14XX, PIC16F15XX and PIC16F17XX, have made a departure from the usual set of peripherals found in previous models to achieve a lower price point while still offering a compelling new set of features. [...]
· High-Endurance Flash (HEF) Block replacing the data EEPROM present on previous models
with a block of Flash memory that is ensured to provide the same high endurance (100,000 erase/write cycles). [...]
The high-endurance block is a block of 128 memory locations, found at the top of the Flash program memory that is ensured to provide a superior endurance, equal to that of a traditional data EEPROM memory within a given temperature range (0°C to 60°C). [...]
It is important to note that the high-endurance Flash memory region is normally assumed to be available to the C compiler for the application code storage. In order to avoid any possible conflict (overlapping code and data usage), it is important to reserve the device-specific memory range by using the --ROM linker switch in the project configuration. [...]
From flash.h:
###ifdefined(_PIC16F1501_H_)####//1K#####defineFLASH_ROWSIZE16//size of a row###defineHEFLASH_START0x0380//first address in HE Flash memory###defineHEFLASH_END0x03FF//last address in HE Flash memory###elifdefined(_PIC16F1503_H_)||defined(_PIC16F1507_H_)||defined(_PIC16F1512_H_)||\
##defined(_PIC16F1703_H_)||defined(_PIC16F1707_H_)####//2K###defineFLASH_ROWSIZE16//size of a row###defineHEFLASH_START0x0780//first address in HE Flash memory###defineHEFLASH_END0x07FF//last address in HE Flash memory###elifdefined(_PIC16F1508_H_)||defined(_PIC16F1513_H_)||\
##defined(_PIC16F1704_H_)||defined(_PIC16F1708_H_)||defined(_PIC16F1713_H_)####//4K###defineFLASH_ROWSIZE32//size of a row###defineHEFLASH_START0x0F80//first address in HE Flash memory###defineHEFLASH_END0x0FFF//last address in HE Flash memory###elifdefined(_PIC16F1509_H_)||defined(_PIC16F1526_H_)||\
##defined(_PIC16F1454_H_)||defined(_PIC16F1455_H_)||defined(_PIC16F1459_H_)||\
##defined(_PIC16F1705_H_)||defined(_PIC16F1709_H_)||\
##defined(_PIC16F1716_H_)||defined(_PIC16F1717_H_)####//8K#####defineFLASH_ROWSIZE32//size of a row###defineHEFLASH_START0x1F80//first address in HE Flash memory###defineHEFLASH_END0x1FFF//last address in HE Flash memory###elifdefined(_PIC16F1518_H)||defined(_PIC16F1519_H)||defined(_PIC16F1527_H_)||\
##defined(_PIC16F1718_H_)||defined(_PIC16F1719_H_)####//16K#####defineFLASH_ROWSIZE32//size of a row###defineHEFLASH_START0x3F80//first address in HE Flash memory###defineHEFLASH_END0x3FFF//last address in HE Flash memory###endif
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
o 50+ devices (in addition to the above 50: PIC10(L)F320, PIC10(L)F322, PIC16(L)F721)
o HEF regions are the same size but location differs due to device memory sizes
o I could find no HEF device which also had EEPROM.
o HEF can be erased like any other program memory
o Constraint OK
o Leave PKCMD+ untouched (see below)
o Leave PK+GUI untouched (see below)
Below :) - The HEF memory may well be used as program memory in which case it would be unwise to treat it similarly to EEPROM.
I think the preferred solution is to add a constraint to the compiler along the lines of the current #option bootloader, say, #option HEF 0x1F80,0x1FFF to stop the compiler using that memory for program storage, or more generically perhaps #option memtop 0x1F7F to introduce a false memory ceiling.
Last edit: Trev 2018-09-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure I understand the do not change the programmers. I was asked earlier this week to preserve HEF memory when programming. So, this needs to be resolved - what is to be done?
And, my view. I would prefer something like #option ProtectHEF with no parameters. I really do not want users having to look up the datahseet when we have resolve that for them in the .dat :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure I understand the do not change the programmers.
The amount of HEF memory being used for its high endurance purpose may not necessarily be the whole amount available, so preserving like EEPROM when programming would be unwise.
I would prefer something like #option ProtectHEF with no parameters.
Same issue as above. If I'm only using 8 of the 128 locations, I might want those extra program words for my program. You cannot write a program for a PIC without checking its datasheet in my experience regardless of which compiler you may be using!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That way it is:
a) protected by default if the device has it
b) may be erased and recreated during debugging
c) may be used as Normal Flash if the space is needed for the main program
As far as I know, HFE has evolved over the years, it began in PIC32 devices as a way to use normal flash in place of EEPROM as the PIC32 MIPS Core had no EEPROM.
When it migrated to the 8 bit devices memory had improved and so a special block of FLASH memory was added to the core to increase read/write cycle life.
The normal way to protect it is to edit the MAKEfile used in the build process, similar to protecting the boot loader, not sure if GCBASIC uses one though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Would you not want to preserve the HEF during programming?
It depends on whether the HEF data has been generated by the program and whether it is intrinsically of value. The problem I foresee again is how many of the HEF locations are in use for their high endurance pupose and how the programmer software could deal with what may be a variable number (and location).
I concede that preserving a specified amount and location of HEF data when programming would be nice-to-have if it was feasible. I just have trouble imagining such a solution.
In the absence of any change to the GUI programmer software, my approach would be (where the existing HEF data was of value) to read the device memory and export it as a file, and either:
1) import the new file, manually alter the relevant HEF locations to restore the HEF data, then program; or
2) splice the old HEF data into the new HEX file with the HEXMATE utility (see http://microchipdeveloper.com/xc8:hexmate-cli ), import and program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Even if the compiler has an option to preserve HEF memory. It will not affect what the programmer does. Command line programmers will still need the option/ability to preserve a specific range of program memory. All the compiler option would do is tell the compiler not to write program code into a specific region of flash memory
With commandline programmers, -m command line swicth tells the programmer what memory areas to program.
Example -mpc should tell the programmer to write to program, and configuration memory. However both areas willl be erased before programming. There is no option not to erase a specific region. So and data in the HEF range of Flash memory will be lost regardless of any compiler options.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
data in the HEF range of Flash memory will be lost regardless of any compiler options.
Yes - I know. I only wanted to ensure that the compiler did not use what it thought was simple program memory when it was in fact HEF which I wanted to reserve for data.
As for how to preserve HEF when programming, I have that under control (see above).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The command line options above will program Configuration Memory & program Flash Memory (CODE) while prserving the 128 Word HEF memory range of 0x1F80 to 0x1FFF.
-MP<range> is poorly documented, but adding the range turns off "autorange" so that entire flash memory is included. If not included, then the Preserve Range setting with -OP<range> will not work and an error will be returned.</range></range>
The above command line options tell IPECMD to:
1) Use PicKit3 (Must be in MPLAB MODE)
2) Use External Power (PK3 Does not power the Chip)
3) Program Flash Memory (GCB Code)
4) Program Config Memory (GCB #Config)
5) Preserve HEF from 0x1F80 to 0X1FFF
6) Release from Reset (MCLRE not Asserted)
Bill
While IPECMD requires installation of MPLABX IPE and is relatively slow, for now, this appears to be the easiest way to reprogram a PIC Microcontroller while preserve HEF memory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I could not see any Great Cow BASIC documentation on whether the compiler excludes the High Endurance Flash memory from available program flash memory. There was nothing related in heflash.h. There was also nothing in the chipdata 16f1619.dat file indicating the start/end of HEF (1F80-1FFF).
Initially I thought I could use #option bootloader but I think the diagram in the help is misleading because it shows the bootloader at the top of memory, but the option actually reserves memory at the bottom of memory (eg the example #option bootloader 0x800 reserves program memory between 0x000 and 0x7FFF for the bootloader with the user program starting after that at 0x800).
So I assume that the HEF memory is not reserved, in which case is there any guarantee that the compiler will not trample over that memory?
(The Microchip xc8 compiler has the —ROM=default,-1f80-1fff compiler option to reserve the HEF memory.)
Let me investigate. Because, I do not know.
As this is the second time I have been asked questions regarding HEF in a week... best, I get the answer.
:=)
As of right now, the only way I know of to preserve HEF memory is to program using the MPLABX IPE GUI application( MPLABX V5.05) The memory settings need to be changed so that the app is not allowed to auto detect memory . And a range to preserve must be entered, The settings shown in the attached screen hot work ok for 16F1619.
IPECMD is suposed to be able to preserve a memory range wth the -OP switch, but it does not work and neither does the -ON switch, These either generate an error or result in a programming failure.
Thanks for that William - but IPE is a whole other can of worms in my experience. I have two PICkit 3s and only one of them (mostly) works with IPE but is always a trial. That's why I signed up for the PICkitPlus software :)
In any event, I'm not sure whether the Great Cow BASIC compiler doesn't trample over that memory - for example, xc8 generally seems to throw ISRs to top of memory something which can be avoded by the compiler option to reserve memory ranges.
I think a more elegant solution is a compiler #option to reserve a memory range which may be useful not just for HEF memory range exclusions.
Luckily we can resolve.
Strategy. Have the compiler protect that region of memory, and, have PICKITPLUS handle the memory appropriately.
For the compiler we need to figure out how to add the memory regionto the .dat file. And, ensure the compiler handles the memory region.
For PICKITPlus we need to simply treat the HEF like EEPROM. We will need to add HEF memory region to the device database and then update the programmer software.
Sounds so easy. It is not.
I am discussing our strategy with Hugh.
Meanwhile.... William/Bill has good insights.
Some design thoughts. I need answers and someone to reseach the answers.
Are the HEF regions the same memory location and size?
Do HEF devices NOT have EEPROM or do some parts have HEF and EEPROM. How many devices of each type?
So, an ERASE in the PICKitPlus GUI or using /e with PKCMD+... would erase the HEF regardless
The EEPROM dialog could be adapted to support HEF - so, you unchecked the 'new' EEPROM/HEF then would READ/RESTORE and VERIFY HEF
What other thoughts?
Last edit: Anobium 2018-09-14
Excerpts from Microchip App Note AN1673 http://ww1.microchip.com/downloads/en/AppNotes/00001673A.pdf
The PIC16F1XXX family of general purpose Flash microcontrollers features the 8-bit PIC® MCU enhanced mid-range core. Carefully trading functionality versus cost, several members of this family, including the PIC16F14XX, PIC16F15XX and PIC16F17XX, have made a departure from the usual set of peripherals found in previous models to achieve a lower price point while still offering a compelling new set of features.
[...]
· High-Endurance Flash (HEF) Block replacing the data EEPROM present on previous models
with a block of Flash memory that is ensured to provide the same high endurance (100,000 erase/write cycles).
[...]
The high-endurance block is a block of 128 memory locations, found at the top of the Flash program memory that is ensured to provide a superior endurance, equal to that of a traditional data EEPROM memory within a given temperature range (0°C to 60°C).
[...]
It is important to note that the high-endurance Flash memory region is normally assumed to be available to the C compiler for the application code storage. In order to avoid any possible conflict (overlapping code and data usage), it is important to reserve the device-specific memory range by using the --ROM linker switch in the project configuration.
[...]
From flash.h:
Specifically:
o 50+ devices (in addition to the above 50: PIC10(L)F320, PIC10(L)F322, PIC16(L)F721)
o HEF regions are the same size but location differs due to device memory sizes
o I could find no HEF device which also had EEPROM.
o HEF can be erased like any other program memory
o Constraint OK
o Leave PKCMD+ untouched (see below)
o Leave PK+GUI untouched (see below)
Below :) - The HEF memory may well be used as program memory in which case it would be unwise to treat it similarly to EEPROM.
I think the preferred solution is to add a constraint to the compiler along the lines of the current #option bootloader, say, #option HEF 0x1F80,0x1FFF to stop the compiler using that memory for program storage, or more generically perhaps #option memtop 0x1F7F to introduce a false memory ceiling.
Last edit: Trev 2018-09-14
Thank you. Brilliant research.
I get the 'do not treat' like EEPROM. Like it.
I am not sure I understand the do not change the programmers. I was asked earlier this week to preserve HEF memory when programming. So, this needs to be resolved - what is to be done?
And, my view. I would prefer something like #option ProtectHEF with no parameters. I really do not want users having to look up the datahseet when we have resolve that for them in the .dat :-)
I am not sure I understand the do not change the programmers.
The amount of HEF memory being used for its high endurance purpose may not necessarily be the whole amount available, so preserving like EEPROM when programming would be unwise.
I would prefer something like #option ProtectHEF with no parameters.
Same issue as above. If I'm only using 8 of the 128 locations, I might want those extra program words for my program. You cannot write a program for a PIC without checking its datasheet in my experience regardless of which compiler you may be using!
Or #option EraseHEF
That way it is:
a) protected by default if the device has it
b) may be erased and recreated during debugging
c) may be used as Normal Flash if the space is needed for the main program
As far as I know, HFE has evolved over the years, it began in PIC32 devices as a way to use normal flash in place of EEPROM as the PIC32 MIPS Core had no EEPROM.
When it migrated to the 8 bit devices memory had improved and so a special block of FLASH memory was added to the core to increase read/write cycle life.
The normal way to protect it is to edit the MAKEfile used in the build process, similar to protecting the boot loader, not sure if GCBASIC uses one though.
@Trev.
Would you not want to preserve the HEF during programming?
I understand now. I get the range bit now. I think we can help users with the potential range - leave that with me.
So, I understand the #option, can you help me with the programming question above.
It depends on whether the HEF data has been generated by the program and whether it is intrinsically of value. The problem I foresee again is how many of the HEF locations are in use for their high endurance pupose and how the programmer software could deal with what may be a variable number (and location).
I concede that preserving a specified amount and location of HEF data when programming would be nice-to-have if it was feasible. I just have trouble imagining such a solution.
In the absence of any change to the GUI programmer software, my approach would be (where the existing HEF data was of value) to read the device memory and export it as a file, and either:
1) import the new file, manually alter the relevant HEF locations to restore the HEF data, then program; or
2) splice the old HEF data into the new HEX file with the HEXMATE utility (see http://microchipdeveloper.com/xc8:hexmate-cli ), import and program.
Even if the compiler has an option to preserve HEF memory. It will not affect what the programmer does. Command line programmers will still need the option/ability to preserve a specific range of program memory. All the compiler option would do is tell the compiler not to write program code into a specific region of flash memory
With commandline programmers, -m command line swicth tells the programmer what memory areas to program.
Example -mpc should tell the programmer to write to program, and configuration memory. However both areas willl be erased before programming. There is no option not to erase a specific region. So and data in the HEF range of Flash memory will be lost regardless of any compiler options.
Yes - I know. I only wanted to ensure that the compiler did not use what it thought was simple program memory when it was in fact HEF which I wanted to reserve for data.
As for how to preserve HEF when programming, I have that under control (see above).
Preserving a range of HEF memory while reprogramming a PIC microcontroller using the IPECMD.exe command line has been solved.
Tested on PIC16F1619. These are the command line options I used with GCB "Programmer Preferences"
-TPPK3 -P%chipmodel% -F"%filename%" -MC -MP0x0000-0x1fff -OP0x1f80-0x1fff -OL
The command line options above will program Configuration Memory & program Flash Memory (CODE) while prserving the 128 Word HEF memory range of 0x1F80 to 0x1FFF.
-MP<range> is poorly documented, but adding the range turns off "autorange" so that entire flash memory is included. If not included, then the Preserve Range setting with -OP<range> will not work and an error will be returned.</range></range>
The above command line options tell IPECMD to:
1) Use PicKit3 (Must be in MPLAB MODE)
2) Use External Power (PK3 Does not power the Chip)
3) Program Flash Memory (GCB Code)
4) Program Config Memory (GCB #Config)
5) Preserve HEF from 0x1F80 to 0X1FFF
6) Release from Reset (MCLRE not Asserted)
Bill
While IPECMD requires installation of MPLABX IPE and is relatively slow, for now, this appears to be the easiest way to reprogram a PIC Microcontroller while preserve HEF memory.