Hello all
Working with the more recent Microchip chips can be a challenge !
Among them is the replacement of EEPROM with HEFM for which the EPWrite/EPRead functions just do not work. Currently (i.e. in the 0.94 hot release version dated 2015-04-02) there are 26 of those chips that have the new HEFM memory, namely :
10f320, 10f322, 12f1501, 16f1454, 16f1455, 16f1459, 16f1503, 16f1507, 16f1508, 16f1509, 16f1512, 16f1513, 16f1516, 16f1517, 16f1518, 16f1519, 16f1526, 16f1527, 16f1703, 16f1704, 16f1705, 16f1707, 16f1708, 16f1709, 16f720, 16f721.
I have therefore written my first hflash.h library that I have extensively tested on a 16f1709
Any feedback, suggestions, corrections are welcome and I leave to Hugh and/or Anobium the decision to integrate it or not in the official distro.
Best
Jacques
Original code removed from this post on June 1st, 2015
The final code (version 1.2) is now available here
and the test program for a 16F1509 is here
Last edit: Jacques Nilo 2015-06-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Jacques. For some reason I failed to notice this HEF feature before. A byproduct of outdated/preliminary data sheets I guess. The 10F320_322 data sheet still fails to acknowledge this HEF, although it is recognized on the Microchip website.
Somehow I have an old example for the 10F322 with MCLRE=OFF working. You would think the LVP would have to be enabled (MCLRE=ON).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kent_twt4: I have a problem with the initialization variables of the 10F320/322 chips.
For the 10F320/322 I found on page 9 of the datasheet
10F320: HEFLASH_START = 0x0F80 HEFLASH_END = 0x00FF
10F322: HEFLASH_START = 0x1F80 HEFLASH_END = 0x01FF
The HEFLASH_START values look wrong since they are much higher than the HEFLASH_END values which look ok.
If we assume 4 rows of 16 words (4 x 16 x 2 = 64 bytes) of HEFM then we should rather have:
10F320: HEFLASH_START = 0x00C0 HEFLASH_END = 0x00FF
10F322: HEFLASH_START = 0x01BC HEFLASH_END = 0x01FF
In which case I should correct the initialization phase for those two chips.
What do you think ?
As far as the MCLRE issue is concerned I noticed that when I was trying to read the chip memory after flashing with Pickit3 a test program which was writing some data into HEFM the corresponding area was not coherent with what was supposed to be written by the test program when the default MCLRE option was OFF. With MCLRE_ON I did not get these problems and everything is working fine. Still not very clear why...
Last edit: Jacques Nilo 2015-05-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Jacques
Definitely a typo in the HEF table for the 10f320 and 10f322 start address. How many bytes of HEF are available? The device description by Microchip says there is 128 Bytes http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC10F322
That would mean 8 rows of 8 words. Looking at the program memory window on the PICKit2 that would mean the start would be 0x01C0 and 0x00C0 for the 10f322 and 10f320 respectively? I would verify with Microchip or their forum on this.
Color me confused when it says "Note 1: High-endurance Flash applies to low byte of each address in the range." No idea what that is supposed to mean?
It is quite possible that having the PICKit2 attached, or the 10f322 dev board had MCLR pin physically pulled up regardless of what I thought the Config was doing. It was a couple of years ago, so a little foggy on that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would mean 8 rows of 8 words. Looking at the program memory window on the PICKit2 that would mean the start would be 0x01C0 and 0x00C0 for the 10f322 and 10f320 respectively? I would verify with Microchip or their forum on this.
OK Let me know when you have got the response so I can fix the HEFLASH_START values for those two chips.
Color me confused when it says "Note 1: High-endurance Flash applies to low byte of each address in the range." No idea what that is supposed to mean?
This is indeed a very intriguing feature of HEFM. Only the low byte of the memory has this High Endurance property and this is only indicated in Microchip datasheets with the same footnote that you mention. Some interesting threads from the Microchip forum on this here, here and here
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the background, glad I'm not the only one confused. I have a 16f1503 and the start and end address seem to indicate as you have documented that only the lower byte is HEF. In my previous post I indicated 8 rows of 8 words, but the data sheet indicates 16 rows of 8 bytes, so My Bad. So based on that, then the lower byte of the start address would be the same as all the others 0xXX80. The 320 would be 0x0080 and the 322 would be 0x0180.
I put a post in the Microchip forum to verify the 128 Bytes of HEF.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I updated the library above to replace the HEFWrite subroutine with a more compact one (and no more bug in it I hope...). So make sure to user the 1.1 version of the heflash.h library.
Also the MLCR issue initially mentionned is solved. A pull up resisor issue on my side :-(
@kent_twt4: The HEFLASH_START values for 10F320/322 are updated
@Anobium: I am sending you a PM as requested
Last edit: Jacques Nilo 2015-05-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Jacques
If we agree on there are only 8 HEF Bytes per row, then how about this in the block write? For my test case of the 16f1503, there would be Flash_rel_addr of 0-15 (rows) which seems more intuitive?
Speaking for Jacques - we are code reviewing and revising. Hope to get a completed version into Sourceforge in a day or two. Jacques has joined the family of developers!!
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello all
Working with the more recent Microchip chips can be a challenge !
Among them is the replacement of EEPROM with HEFM for which the EPWrite/EPRead functions just do not work. Currently (i.e. in the 0.94 hot release version dated 2015-04-02) there are 26 of those chips that have the new HEFM memory, namely :
10f320, 10f322, 12f1501, 16f1454, 16f1455, 16f1459, 16f1503, 16f1507, 16f1508, 16f1509, 16f1512, 16f1513, 16f1516, 16f1517, 16f1518, 16f1519, 16f1526, 16f1527, 16f1703, 16f1704, 16f1705, 16f1707, 16f1708, 16f1709, 16f720, 16f721.
I have therefore written my first hflash.h library that I have extensively tested on a 16f1709
Any feedback, suggestions, corrections are welcome and I leave to Hugh and/or Anobium the decision to integrate it or not in the official distro.
Best
Jacques
Original code removed from this post on June 1st, 2015
The final code (version 1.2) is now available here
and the test program for a 16F1509 is here
Last edit: Jacques Nilo 2015-06-02
This looks like a great piece of work.
Send me a personal message with your email address I will discuss publishing.
Thank you!!
Thanks Jacques. For some reason I failed to notice this HEF feature before. A byproduct of outdated/preliminary data sheets I guess. The 10F320_322 data sheet still fails to acknowledge this HEF, although it is recognized on the Microchip website.
Somehow I have an old example for the 10F322 with MCLRE=OFF working. You would think the LVP would have to be enabled (MCLRE=ON).
@kent_twt4: I have a problem with the initialization variables of the 10F320/322 chips.
For the 10F320/322 I found on page 9 of the datasheet
10F320: HEFLASH_START = 0x0F80 HEFLASH_END = 0x00FF
10F322: HEFLASH_START = 0x1F80 HEFLASH_END = 0x01FF
The HEFLASH_START values look wrong since they are much higher than the HEFLASH_END values which look ok.
If we assume 4 rows of 16 words (4 x 16 x 2 = 64 bytes) of HEFM then we should rather have:
10F320: HEFLASH_START = 0x00C0 HEFLASH_END = 0x00FF
10F322: HEFLASH_START = 0x01BC HEFLASH_END = 0x01FF
In which case I should correct the initialization phase for those two chips.
What do you think ?
As far as the MCLRE issue is concerned I noticed that when I was trying to read the chip memory after flashing with Pickit3 a test program which was writing some data into HEFM the corresponding area was not coherent with what was supposed to be written by the test program when the default MCLRE option was OFF. With MCLRE_ON I did not get these problems and everything is working fine. Still not very clear why...
Last edit: Jacques Nilo 2015-05-24
@Jacques
Definitely a typo in the HEF table for the 10f320 and 10f322 start address. How many bytes of HEF are available? The device description by Microchip says there is 128 Bytes http://www.microchip.com/wwwproducts/Devices.aspx?product=PIC10F322
That would mean 8 rows of 8 words. Looking at the program memory window on the PICKit2 that would mean the start would be 0x01C0 and 0x00C0 for the 10f322 and 10f320 respectively? I would verify with Microchip or their forum on this.
Color me confused when it says "Note 1: High-endurance Flash applies to low byte of each address in the range." No idea what that is supposed to mean?
It is quite possible that having the PICKit2 attached, or the 10f322 dev board had MCLR pin physically pulled up regardless of what I thought the Config was doing. It was a couple of years ago, so a little foggy on that.
@kent_twt4
OK Let me know when you have got the response so I can fix the HEFLASH_START values for those two chips.
This is indeed a very intriguing feature of HEFM. Only the low byte of the memory has this High Endurance property and this is only indicated in Microchip datasheets with the same footnote that you mention. Some interesting threads from the Microchip forum on this here, here and here
@Jacques
Thanks for the background, glad I'm not the only one confused. I have a 16f1503 and the start and end address seem to indicate as you have documented that only the lower byte is HEF. In my previous post I indicated 8 rows of 8 words, but the data sheet indicates 16 rows of 8 bytes, so My Bad. So based on that, then the lower byte of the start address would be the same as all the others 0xXX80. The 320 would be 0x0080 and the 322 would be 0x0180.
I put a post in the Microchip forum to verify the 128 Bytes of HEF.
I updated the library above to replace the HEFWrite subroutine with a more compact one (and no more bug in it I hope...). So make sure to user the 1.1 version of the heflash.h library.
Also the MLCR issue initially mentionned is solved. A pull up resisor issue on my side :-(
@kent_twt4: The HEFLASH_START values for 10F320/322 are updated
@Anobium: I am sending you a PM as requested
Last edit: Jacques Nilo 2015-05-25
@Jacques
If we agree on there are only 8 HEF Bytes per row, then how about this in the block write? For my test case of the 16f1503, there would be Flash_rel_addr of 0-15 (rows) which seems more intuitive?
Jacques,
Thank you, this is exactly what I need!
Randy
Speaking for Jacques - we are code reviewing and revising. Hope to get a completed version into Sourceforge in a day or two. Jacques has joined the family of developers!!
Thank you.
Here you are ! See following thread