>
> Hi!
> it is my understanding that runtime programming of the non-volatile memory
> of the PIC32 is much less useful than it used to be on the dsPIC:
>
> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
> allowed erase and programming of very small Program Flash memory regions,
> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
> re-program it, even just to update a single variable!
>
> Even worse, if you just want to updated e.g. a non-volatile counter, not
> only you must erase 4KB of Program Memory and reprogram it from scratch,
> but you clear also need a 4KB temporary RAM buffer to hold the original
> data, modify it in RAM, and then erase and program the whole 4KB chunk (!).
>
> Is it really like this or I'm dreaming (incubus..)?
>
> For example this completely rules out the PIC32MX110F016B, as it only has
> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
> the limiting factor is the RAM.
>
> With kind regards,
> Mario
>

> Mario,
>
> I think this topic has been discussed here a number of times. For instance
> PIC24 has pretty much the same limitation.
>
> The way you may want to work is not re-writting the whole 4KB block
> everytime, but with a bit more ellaborated algorithm, update your variable
> in a subset of the region with increasing address, and always read from the
> last one you sign in any particular way is useful in your application (e.g.
> one byte for actual data, next byte for marking "data used" with anything
> different than 0xFF). That increase flash lifetime as reduce erase cycles,
> but also reduce the number of times you need to go to the expensive whole
> block erase/rewrite.
>
> Another option is to alternatively use 2 blocks of flash, 4KB each, one
> will swap into the other once is full, and act as a backup so you can
> freely erase one block and keep the other one, with basically no use of RAM
> for that.
>
> Also note you need to use 4KB of RAM if all the memory positions are
> actually useful (real data) otherwise you need only a fraction of that to
> maintain your real data only, not the whole block.
>
> Welcome to the non-EEPROM MCU world, anyway ;)
>

>
> Hi!
> it is my understanding that runtime programming of the non-volatile memory
> of the PIC32 is much less useful than it used to be on the dsPIC:
>
> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
> allowed erase and programming of very small Program Flash memory regions,
> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
> re-program it, even just to update a single variable!
>
> Even worse, if you just want to updated e.g. a non-volatile counter, not
> only you must erase 4KB of Program Memory and reprogram it from scratch,
> but you clear also need a 4KB temporary RAM buffer to hold the original
> data, modify it in RAM, and then erase and program the whole 4KB chunk
> (!).
>
> Is it really like this or I'm dreaming (incubus..)?
>
> For example this completely rules out the PIC32MX110F016B, as it only has
> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
> the limiting factor is the RAM.

>Mario,
>
>I think this topic has been discussed here a number of times. For instance
>PIC24 has pretty much the same limitation.
>
>The way you may want to work is not re-writting the whole 4KB block
>everytime, but with a bit more ellaborated algorithm, update your variable
>in a subset of the region with increasing address, and always read from the
>last one you sign in any particular way is useful in your application (e.g..
>one byte for actual data, next byte for marking "data used" with anything
>different than 0xFF). That increase flash lifetime as reduce erase cycles,
>but also reduce the number of times you need to go to the expensive whole
>block erase/rewrite.

>--
>Ariel Rocholl
>http://www.rf-explorer.com
>
>On Wed, May 30, 2012 at 4:44 PM, Electron <.....electron2k4KILLspam@spam@infinito.it> wrote:
>
>>
>> Hi!
>> it is my understanding that runtime programming of the non-volatile memory
>> of the PIC32 is much less useful than it used to be on the dsPIC:
>>
>> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
>> allowed erase and programming of very small Program Flash memory regions,
>> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
>> re-program it, even just to update a single variable!
>>
>> Even worse, if you just want to updated e.g. a non-volatile counter, not
>> only you must erase 4KB of Program Memory and reprogram it from scratch,
>> but you clear also need a 4KB temporary RAM buffer to hold the original
>> data, modify it in RAM, and then erase and program the whole 4KB chunk (!).
>>
>> Is it really like this or I'm dreaming (incubus..)?
>>
>> For example this completely rules out the PIC32MX110F016B, as it only has
>> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
>> the limiting factor is the RAM.
>>
>> With kind regards,
>> Mario
>>

>On Wed, May 30, 2012 9:44 am, Electron wrote:
>>
>> Hi!
>> it is my understanding that runtime programming of the non-volatile memory
>> of the PIC32 is much less useful than it used to be on the dsPIC:
>>
>> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
>> allowed erase and programming of very small Program Flash memory regions,
>> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
>> re-program it, even just to update a single variable!
>>
>> Even worse, if you just want to updated e.g. a non-volatile counter, not
>> only you must erase 4KB of Program Memory and reprogram it from scratch,
>> but you clear also need a 4KB temporary RAM buffer to hold the original
>> data, modify it in RAM, and then erase and program the whole 4KB chunk
>> (!).
>>
>> Is it really like this or I'm dreaming (incubus..)?
>>
>> For example this completely rules out the PIC32MX110F016B, as it only has
>> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
>> the limiting factor is the RAM.
>
>You really need to dig deep into Section 5 of the PIC32 family reference
>manual.  I haven't done a PIC32 bootloader, but the process isn't all that
>different between parts. The PIC32 (like all PICs) when doing
>self-programming, must erase a full page (at least)- in the case of the
>PIC32- 4KBytes. But when programming, you can program a single word (4
>Bytes) or a row, 128 words (512 Bytes).
>
>Don't forget that "erasing" a flash cell is really setting the value to
>"1" While I haven't done it on a PIC32, you can do some tricks on other
>PICs, such as telling it to program a "1" to a cell that is already zero-
>in that case (on the PIC18s I remember most clearly, I suspect that PIC32
>will act the same way), nothing happens- programming will only set a flash
>cell low- you have to do a full page erase to set any cell high.
>
>Regards,
>
>Matt Bennett
>Just outside of Austin, TX
>30.51,-97.91
>
>The views I express are my own, not that of my employer, a large
>multinational corporation that you are familiar with.

>
>Dear Ariel,
>
>
>At 17.06 2012.05.30, you wrote:
>>Mario,
>>
>>I think this topic has been discussed here a number of times. For instance
>>PIC24 has pretty much the same limitation.
>>
>>The way you may want to work is not re-writting the whole 4KB block
>>everytime, but with a bit more ellaborated algorithm, update your variable
>>in a subset of the region with increasing address, and always read from the
>>last one you sign in any particular way is useful in your application (e.g.
>>one byte for actual data, next byte for marking "data used" with anything
>>different than 0xFF). That increase flash lifetime as reduce erase cycles,
>>but also reduce the number of times you need to go to the expensive whole
>>block erase/rewrite.
>
>Yes, it is my understanding that programming "0"'s in FLASH memory can be
>done any time, the problem is when you need to program "1"'s, in which case
>you must erase the whole page. Is this correct?
>
>So it is actually the erase the "consumes the life" of the FLASH memory,
>not the program ("set bit to 0") phase?
>
>
>>Another option is to alternatively use 2 blocks of flash, 4KB each, one
>>will swap into the other once is full, and act as a backup so you can
>>freely erase one block and keep the other one, with basically no use of RAM
>>for that.
>>
>>Also note you need to use 4KB of RAM if all the memory positions are
>>actually useful (real data) otherwise you need only a fraction of that to
>>maintain your real data only, not the whole block.
>
>Yes, of course, and I even thought about compressing/inflating the data,
>but you don't have a guarantee about compression ratios, and anyway in the
>MPU world we already tend to fit as much as possible into memory so.. ;)
>
>
>>Welcome to the non-EEPROM MCU world, anyway ;)
>
>:D
>
>
>>Hope this helps.
>
>Thanks.
>
>Cheers,
>MarI/O
>
>
>>--
>>Ariel Rocholl
>>http://www.rf-explorer.com
>>
>>On Wed, May 30, 2012 at 4:44 PM, Electron <electron2k4KILLspaminfinito.it> wrote:
>>
>>
>> Hi!
>> it is my understanding that runtime programming of the non-volatile memory
>> of the PIC32 is much less useful than it used to be on the dsPIC:
>>
>> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
>> allowed erase and programming of very small Program Flash memory regions,
>> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
>> re-program it, even just to update a single variable!
>>
>> Even worse, if you just want to updated e.g. a non-volatile counter, not
>> only you must erase 4KB of Program Memory and reprogram it from scratch,
>> but you clear also need a 4KB temporary RAM buffer to hold the original
>> data, modify it in RAM, and then erase and program the whole 4KB chunk (!).
>>
>> Is it really like this or I'm dreaming (incubus..)?
>>
>> For example this completely rules out the PIC32MX110F016B, as it only has
>> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
>> the limiting factor is the RAM.
>>
>> With kind regards,
>> Mario
>>

>
> Dear Matt,
>
> Thanks, all is more clear now.
>
> Speaking about boot loaders, I was much interested in the following but
> the link
> is broken, and extensive googling didn't help at all.. as you work for "a
> large
> multinational corporation that we are familiar with" ;) could you help to
> fix
> that broken link please?
>
> http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en025788
>
> If I click on the file to download it, the following link results broken:
>
> http://ww1.microchip.com/downloads/en/studioresource/en002814.zip
>
> As I wrote, there was no way for me to find en002814.zip anywhere on the
> Net.
>
> It's a serial bootloader for PIC32.. just what I need! Although I'm
> writing my
> own, that may be a good reference anyway for me to peek at.

>
>Isaac
>
>
>
>------------------------------
>Em qui, 31 de mai de 2012 09:27 BRT Electron escreveu:
>
>>
>>Dear Ariel,
>>
>>
>>At 17.06 2012.05.30, you wrote:
>>>Mario,
>>>
>>>I think this topic has been discussed here a number of times. For instance
>>>PIC24 has pretty much the same limitation.
>>>
>>>The way you may want to work is not re-writting the whole 4KB block
>>>everytime, but with a bit more ellaborated algorithm, update your variable
>>>in a subset of the region with increasing address, and always read from the
>>>last one you sign in any particular way is useful in your application (e..g.
>>>one byte for actual data, next byte for marking "data used" with anything
>>>different than 0xFF). That increase flash lifetime as reduce erase cycles,
>>>but also reduce the number of times you need to go to the expensive whole
>>>block erase/rewrite.
>>
>>Yes, it is my understanding that programming "0"'s in FLASH memory can be
>>done any time, the problem is when you need to program "1"'s, in which case
>>you must erase the whole page. Is this correct?
>>
>>So it is actually the erase the "consumes the life" of the FLASH memory,
>>not the program ("set bit to 0") phase?
>>
>>
>>>Another option is to alternatively use 2 blocks of flash, 4KB each, one
>>>will swap into the other once is full, and act as a backup so you can
>>>freely erase one block and keep the other one, with basically no use of RAM
>>>for that.
>>>
>>>Also note you need to use 4KB of RAM if all the memory positions are
>>>actually useful (real data) otherwise you need only a fraction of that to
>>>maintain your real data only, not the whole block.
>>
>>Yes, of course, and I even thought about compressing/inflating the data,
>>but you don't have a guarantee about compression ratios, and anyway in the
>>MPU world we already tend to fit as much as possible into memory so.. ;)
>>
>>
>>>Welcome to the non-EEPROM MCU world, anyway ;)
>>
>>:D
>>
>>
>>>Hope this helps.
>>
>>Thanks.
>>
>>Cheers,
>>MarI/O
>>
>>
>>>--
>>>Ariel Rocholl
>>>http://www.rf-explorer.com
>>>
>>>On Wed, May 30, 2012 at 4:44 PM, Electron <.....electron2k4KILLspam.....infinito.it> wrote:
>>>
>>>
>>> Hi!
>>> it is my understanding that runtime programming of the non-volatile memory
>>> of the PIC32 is much less useful than it used to be on the dsPIC:
>>>
>>> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
>>> allowed erase and programming of very small Program Flash memory regions,
>>> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
>>> re-program it, even just to update a single variable!
>>>
>>> Even worse, if you just want to updated e.g. a non-volatile counter, not
>>> only you must erase 4KB of Program Memory and reprogram it from scratch,
>>> but you clear also need a 4KB temporary RAM buffer to hold the original
>>> data, modify it in RAM, and then erase and program the whole 4KB chunk (!).
>>>
>>> Is it really like this or I'm dreaming (incubus..)?
>>>
>>> For example this completely rules out the PIC32MX110F016B, as it only has
>>> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
>>> the limiting factor is the RAM.
>>>
>>> With kind regards,
>>> Mario
>>>

>
>
>It seems that my first post was lost.
>
>Microchip's AN1095 solves exactly this problem.
>
>Isaac
>
>
>
>------------------------------
>Em qui, 31 de mai de 2012 09:27 BRT Electron escreveu:
>
>>
>>Dear Ariel,
>>
>>
>>At 17.06 2012.05.30, you wrote:
>>>Mario,
>>>
>>>I think this topic has been discussed here a number of times. For instance
>>>PIC24 has pretty much the same limitation.
>>>
>>>The way you may want to work is not re-writting the whole 4KB block
>>>everytime, but with a bit more ellaborated algorithm, update your variable
>>>in a subset of the region with increasing address, and always read from the
>>>last one you sign in any particular way is useful in your application (e..g.
>>>one byte for actual data, next byte for marking "data used" with anything
>>>different than 0xFF). That increase flash lifetime as reduce erase cycles,
>>>but also reduce the number of times you need to go to the expensive whole
>>>block erase/rewrite.
>>
>>Yes, it is my understanding that programming "0"'s in FLASH memory can be
>>done any time, the problem is when you need to program "1"'s, in which case
>>you must erase the whole page. Is this correct?
>>
>>So it is actually the erase the "consumes the life" of the FLASH memory,
>>not the program ("set bit to 0") phase?
>>
>>
>>>Another option is to alternatively use 2 blocks of flash, 4KB each, one
>>>will swap into the other once is full, and act as a backup so you can
>>>freely erase one block and keep the other one, with basically no use of RAM
>>>for that.
>>>
>>>Also note you need to use 4KB of RAM if all the memory positions are
>>>actually useful (real data) otherwise you need only a fraction of that to
>>>maintain your real data only, not the whole block.
>>
>>Yes, of course, and I even thought about compressing/inflating the data,
>>but you don't have a guarantee about compression ratios, and anyway in the
>>MPU world we already tend to fit as much as possible into memory so.. ;)
>>
>>
>>>Welcome to the non-EEPROM MCU world, anyway ;)
>>
>>:D
>>
>>
>>>Hope this helps.
>>
>>Thanks.
>>
>>Cheers,
>>MarI/O
>>
>>
>>>--
>>>Ariel Rocholl
>>>http://www.rf-explorer.com
>>>
>>>On Wed, May 30, 2012 at 4:44 PM, Electron <EraseMEelectron2k4spam_OUTTakeThisOuTinfinito.it> wrote:
>>>
>>>
>>> Hi!
>>> it is my understanding that runtime programming of the non-volatile memory
>>> of the PIC32 is much less useful than it used to be on the dsPIC:
>>>
>>> not only the PIC32 has no EEPROM memory but also, unlike the dsPIC which
>>> allowed erase and programming of very small Program Flash memory regions,
>>> on the PIC32 you must erase 4KB (!) of Program Flash memory in order to
>>> re-program it, even just to update a single variable!
>>>
>>> Even worse, if you just want to updated e.g. a non-volatile counter, not
>>> only you must erase 4KB of Program Memory and reprogram it from scratch,
>>> but you clear also need a 4KB temporary RAM buffer to hold the original
>>> data, modify it in RAM, and then erase and program the whole 4KB chunk (!).
>>>
>>> Is it really like this or I'm dreaming (incubus..)?
>>>
>>> For example this completely rules out the PIC32MX110F016B, as it only has
>>> 4KB of RAM.. having that extra boot flash memory doesn't help here, when
>>> the limiting factor is the RAM.
>>>
>>> With kind regards,
>>> Mario
>>>

>On Thu, May 31, 2012 8:27 am, Electron wrote:
>>
>> Dear Matt,
>>
>> Thanks, all is more clear now.
>>
>> Speaking about boot loaders, I was much interested in the following but
>> the link
>> is broken, and extensive googling didn't help at all.. as you work for "a
>> large
>> multinational corporation that we are familiar with" ;) could you help to
>> fix
>> that broken link please?
>>
>>
>www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId
>=1824&appnote=en025788
>>
>> If I click on the file to download it, the following link results broken:
>>
>> ww1.microchip.com/downloads/en/studioresource/en002814.zip
>>
>> As I wrote, there was no way for me to find en002814.zip anywhere on the
>> Net.
>>
>> It's a serial bootloader for PIC32.. just what I need! Although I'm
>> writing my
>> own, that may be a good reference anyway for me to peek at.
>
>I have absolutely no idea what you are talking about. I speak only for
>myself, of course. And the voices in my head, but they are part of me,
>right?
>
>Just doing a little poking around of the Microchip website- There is an
>app note that talks about various ways to bootload, including UART- it has
>some pretty recent updates- could be that the old file was superseded. The
>app note is AN1388:
><http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeI>d=1824&appnote=en554836>
>
>Regards,
>
>Matt Bennett
>Just outside of Austin, TX
>30.51,-97.91
>
>The views I express are my own, not that of my employer, a large
>multinational corporation that you are familiar with.