[Explained] write_program_memory < FLASH_WRITE_SIZE?

[allenhuffman]

Hoping someone knows the answer before I write a test program to figure this out:

[Ttelmah]

The minimum that can be written is MIN_FLASH_WRITE, Hardware limitation.
However it doesn't do a read then write. You can only set bits to '0' from '1'.
If a bit needs to be set to '1' that it already '0', you will have to erase the
block first. Erased program memory holds '1'.

[allenhuffman]

[Ttelmah]

Yes, but the remaining bytes in the min size, would have indeterminate
values. They'd actually be whatever the write latches contained before
the instruction.

[allenhuffman]

[allenhuffman]

Hey, do you know how erase_program_memory() behaves if you give it an address that is not a block start?

i.e.,

[Ttelmah]

Read the data sheet....

If you trigger an erase, it erases the entire block, and ignores the low bits
of the address loaded into the address registers.

So it'll erase from the start of the block containing the address to the end.

[allenhuffman]

[Ttelmah]

Yes, totally.

This is actually how the virtual EEPROM driver works.
You use a small structure each of which contains the address that if being
stored, and the value to store. Every time you write a value to the virtual
EEPROM, it walks through the page till it finds the first unused location,
then writes the structure defining the new byte. If you change a value
it changes the address to a value signifying 'erased', and adds a new block
with the new value.
When it gets to the end of the page doing this it retrieves all values not
flagged as 'erased', or 'unused', and writes these into the next page then
erases the page originally being used.

[allenhuffman]

I just tried a more complex test on real hardware where I basically did something like this (data is a buffer of values I change it time; hex dump after each statement shows what it tried to program):

[allenhuffman]

I implemented a PIC24 flash programming routine similar to the one I wrote for an external flash part. Now I can write any values and it handles it. It will read the flash block first, then overlay the user writes into that buffer, then when done (or moving to a different block), it will write the whole block out.

The end result is I can write "proper" code that always starts on a FLASH_ERASE_SIZE boundry (to erase it first) and fill it up with FLASH_WRITE_SIZE blocks, or I can just write 5 bytes in the middle and it will read the old data, overlay my new data, and write it out when I am done.

Here is a simple example that does a series of flashProgram() writes from data from the HEX file. i.e, if there is a block in the HEX file at 0x4000, it ends up in the PIC24 flash at 0x2000.

Each step, "data" is initialized with a series of bytes of the same value, incremented at each write step:

[Ttelmah]

If you had read my post a while ago, I referred you to 'MIN_FLASH_WRITE'.
This is the minimum size data that the CCS functions will actually write.
Not the block size of the hardware page, but the minimum the function can
transfer.
You initial tests were trying to write less than this, which is why you got
the unexpected results.
Data must also be in a multiple of this size.:

[allenhuffman]

[jeremiah]

[allenhuffman]