 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
| MIN_FLASH_WRITE |
 Posted: Sat Dec 07, 2019 1:42 pm |
 |
|
While look at the getenv() docs, I see two entires with similar descriptions.
What is MIN_FLASH_WRITE (returns a 4 on my current system) versus FLASH_WRITE_SIZE?
They both start with "smallest number of bytes that can be written to flash". The other one shows me something that looks like alignment, perhaps, versus the amount one can write?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19225
|
|
| Posted: Sat Dec 07, 2019 2:24 pm |
|
|
MIN_FLASH_WRITE is the minimum supported by the CCS instruction.
FLASH_WRITE_SIZE is the hardware write lower limit.
When working with the CCS code it is better to use MIN_FLASH_WRITE. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Sat Dec 07, 2019 2:41 pm |
|
|
My MIN_FLASH_WRITE says 4... FLASH_WRITE_SIZE says 256.
If I went by the CCS 4, wouldn’t that violate the HW 256?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1317
|
|
| Posted: Sat Dec 07, 2019 4:51 pm |
|
|
| allenhuffman wrote: | My MIN_FLASH_WRITE says 4... FLASH_WRITE_SIZE says 256.
If I went by the CCS 4, wouldn’t that violate the HW 256? |
Remember how the program memory is laid out as 3 bytes with a 4th byte of 0 (4 bytes). MIN_FLASH_WRITE is related to that. The smallest value write_program_memory can do in its logic is a 4 bytes together (or an instruction size counting the "0" byte).
FLASH_WRITE_SIZE is how much actually gets written when you the actual HW instruction is called.
So yes, if you were to only write 4 bytes, it would violate the size, and the result is whatever was sitting in the HW fifo of the 256 byte row, would get written to the other places. That might simply just be "unwritten" values (0x00FFFFFF) or it might be something else. I don't remember off the top of my head. So one define is for the CCS logic (4 bytes) and one is for the HW instruction (256 bytes). You have to be aware of both when writing to FLASH.
You're best bet is to read the data sheet for your PIC and see what it says happens if you don't fill the entire 256 byte row up before writing. It might just ignore those bites, or it might not...I don't remember off hand. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Sat Dec 07, 2019 6:15 pm |
|
|
Ah, this makes sense. The SPI part I dealt with had a buffer and for the best efficiency you’d fill it up and tell it to write the whole thing. This sounds like that.
CCS can out four bytes into it, but when it comes time to flush it out, there could be unexpected data there.
What actually triggers it to write to the hardware? Does every use of write_program_memory() do that immediately? Thus you can’t to build and write a block of 256 (in my example) and doing 4 is just an FYI and not something you’d actually ever do?
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1317
|
|
| Posted: Sat Dec 07, 2019 6:47 pm |
|
|
| allenhuffman wrote: | Ah, this makes sense. The SPI part I dealt with had a buffer and for the best efficiency you’d fill it up and tell it to write the whole thing. This sounds like that.
CCS can out four bytes into it, but when it comes time to flush it out, there could be unexpected data there.
What actually triggers it to write to the hardware? Does every use of write_program_memory() do that immediately? Thus you can’t to build and write a block of 256 (in my example) and doing 4 is just an FYI and not something you’d actually ever do? |
Well it depends on what is in that unused part of the write buffer, if it is just 0x00FFFFFF, that is equivalent to not writing a value (larger discussion, just go with it for now). If that is the case, you can write 4 bytes at a time, it will just be very inefficient timewise because each write may take 5-10ms and you cannot run any code (interrupts or other) during that time. If it has junk, then you need to manage a RAM buffer of the correct size and fill that up and then call write_program_memory().
my GUESS is that it writes 0x00FFFFFF in the unused space so it is ok, just an inefficient use of time. But check your datasheet and family reference manuals...I haven't done this in years manually...so I forget exactly what it does for the unused values.
The reason is every call to write_program_memory() will issue a "row" write.
write_program_memory() if a very low level call with very little smarts. Assume it does not do very smart work for you. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Sat Dec 07, 2019 6:55 pm |
|
|
I took care of all the smarts, no worries. Though what it does under the hood to make it do that makes me cringe, but hey, if they really want to change ONE byte in a page, they can do it. Lather, rinse, repeat.
You know, the FF thing is something I hadn’t thought about. If I was sequentially writing, like a data logger (eep, not on program memory, but let’s say I wanted to), I could always write out my data and FFs to fill the page. It would fill the page, leaving the rest untouched. If I jumped forward and wrote a few bytes, same thing, it would work, then I could jump to the middle... until it was all filled or you wrote on top of something else changing those 1s to 0s and making a mess.
Interesting idea.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
jeremiah
Joined: 20 Jul 2010
Posts: 1317
|
|
| Posted: Sat Dec 07, 2019 7:03 pm |
|
|
based on the simple driver I provided here years ago, I think it just writes 0x00FFFFFF to the unused spots, so it is safe to right 4 at a time (again, with a large time inefficiency:
https://www.ccsinfo.com/forum/viewtopic.php?t=52680&highlight=pic24+eeprom+program+programme+memory
There I don't prefill unused bytes, so I am willing to bet I found that it prefilled them with '1's which is the same as not writing anything there.
The nice thing is writing 0xFF to flash is essentially a NOP when writing flash since writing is essentially "burning in 0's and unburned bits are 1's" |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19225
|
|
| Posted: Sun Dec 08, 2019 5:24 am |
|
|
You don't write the entire page when you do this. From MicroChip:
| Quote: |
All 16-bit PIC MCUs allow the application program to specify individual flash memory words to be written.
|
This is the single element write, as opposed to the page write. The 'element'
here is a single instruction word. There is no change to the other words
in the write page.
This is distinct from the 'page write', where all the write latches are updated
and a whole page written at once.
So they don't "write 0x00FFFFFF to the unused spots". They just don't
involve these at all.
Have a look at DS30009715D. This explains all the programming modes
restrictions and effects.
The single write with an element the size of 'MIN_FLASH_WRITE', is
what is described in 4.2.4.1. a program involving FLASH_WRITE_SIZE
is what is described in 4.2.4.3.
This is the 'flash page write'.
Beware though. Though MicroChip say that all the 16bit chips support the
single instruction word write, they have in the notes on this, the comment:
| Quote: |
It is available only in devices with unmapped write latches.
|
So they are both saying it is available on all devices, and that it may not
be.....
The exceptions here are chips where the write latches are memory
mapped.
On these you can actually table read the ROM directly into the write
latches, change just the byte you want, and trigger a table write. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Tue Dec 10, 2019 8:52 am |
|
|
Do you think there is any more wear-and-tear on the flash part if you do 8 256-byte writes to a page, versus 1 2048 write?
And some background on why I've been doing this...
For my implementation, I either read the FLASH_ERASE_SIZE page first, then add my bytes, and write everything back ("preserve data" mode), or I do a normal mode where the caller has to understand that they need to write to the start of the page first and if they do, the entire page gets erased.
Our current implementation was designed to split up the flash into two partitions. The designer had plans to have fallback recovery in case of a bad update. We update partition 1, and it updates the vector table to point to there there. Then next time, we update partition 2, and it updates the vector table to point to there. (The recovery part was never implemented.)
When updating partition 2, our code would read that first page (so it could save the start of app code in partition 1), apply the vector table for partition 2, and write it back. A failure at that point could render the system unbootable and require a debugger to load good firmware.
That's what led me into this bootloader project.
If I were to improve my flash programming code, I'd give it the option of knowing if a page was erased, and then doing writes every FLASH_WRITE_SIZE as data comes in, rather than caching a whole FLASH_ERASE_SIZE block and then writing it all at ones. For firmware updates, where large contiguous blocks come in, cashing the whole sector is more efficient, but I could see a low-memory use-case for something that only had 256 bytes of cache rather than a 2K cache.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19225
|
|
| Posted: Tue Dec 10, 2019 12:15 pm |
|
|
Potentially yes.
What is the write page size on your chip?. Not the erase page, but the
write page (how many write latches it has). Any write smaller than the
number of write latches results in extra lives being used.
Most only have 256, so in which case the answer will be 'no', but if
your chip has more then the answer is yes. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
