Reading, writing, erasing flash (16F88)

[RussMartin]

I'm taking trepidant steps toward using superfluous flash memory for recording data by implementing ERASECODE, WRITECODE, and READCODE.

I'm shuffling back and forth between the PBP manual and the 'F88 data sheet (sections 3.5-3.7) and I'm befuddled.


1. When a block of 32 words is erased, what value is written to each word to represent erasure? $3FFF. $0000? Something else?

2. Since (according to the data sheet) the write function writes a block of 4 words at a time, when the PBP command

WRITECODE Address, Value

is used, if Value is written into Address+0, what is written into addresses Address+1, Address+2, and Address+3?

3. Is the "erase before write" mandatory or simply advisory, and, if truly required,

4. How does the write function determine whether the address location has been erased?

5. And what happens if WRITECODE is invoked without a prior erasure?


What I'm trying to get a feel for, in advance, is:


A. As needed, can I simply do a WRITECODE to Address and then, next time, do a WRITECODE to Address+1 or will I need to

B. WRITECODE to Address, then, when needed, have to do an ERASECODE Address+1 and then WRITECODE Address+1? And

C. Having written a few or several values, is there a value I can look for that shows where I stopped writing (hence question 1 above)?

[skimask]

1 - Most, I say most, eeproms/flash are erased to logic 1 and programmed to logic 0...Most that isl, but I haven't found one that's the opposite.

2 - I assume nothing, therefore they should read back as $FFFF

3 - mandatory I would think. Otherwise you'd just be OR'ing bits...

4 - Probably by ignoring the lowest significant 2 bits in the address

5. #3

A, B, C - I'm fairly sure you have to do everything in the 4 byte blocks, read, erase, write back...

[RussMartin]

1 - Most, I say most, eeproms/flash are erased to logic 1 and programmed to logic 0...Most that isl, but I haven't found one that's the opposite.

My short stock of 16F88s arrived by UPS, so I read a few straight out of the tube. All flash locations were $0000, and those PICs of course failed the blank check. Then I erased one and read it back in hex. All flash locations are initialized to $3FFF to be "blank", so that's settled.

2 - I assume nothing, therefore they should read back as $FFFF

$FFFF is a 16-bit value, so you must have assumed a 16-bit word. Since the words in flash are only 14 bits, the math says $3FFF is the largest value possible. The data sheet (3.7) makes clear that the contents of 4 successive buffer registers are written, and that after a "long write", the buffers are reset to $3FFF. As long as neither WRITECODE nor anything else meddles with what's in those buffers, there should be no problem.

3 - mandatory I would think. Otherwise you'd just be OR'ing bits...

Do you know this, or are you guessing? I don't see how ORing bits is relevant to the question, but I'm anxious to be informed.

4 - Probably by ignoring the lowest significant 2 bits in the address

Okay, you've lost me on this one. Please explain: How does disregarding the 2 least significant bits of the address relate to the value stored at that address?

5. #3

Yes, but what actually happens? Does anyone know from experience, accidental or otherwise?

A, B, C - I'm fairly sure you have to do everything in the 4 byte blocks, read, erase, write back...

Well, the data sheet seems to disagree. According to it: A read returns 1 word from flash; a write must be done as a block of 4 words; and an erase must be done as a block of 32 words.

So my questions A and B remain unanswered, but it appears we can be confident that the answer to question C is, "Yes. The value to look for is $3FFF."

Presumably, one "master" erase of many 32-word blocks would be sufficient for a large number of successive writes.

[skimask]

All flash locations were $0000, and those PICs of course failed the blank check. Then I erased one and read it back in hex. All flash locations are initialized to $3FFF to be "blank", so that's settled.

Never tried it like that...interesting...

$FFFF is a 16-bit value, so you must have assumed a 16-bit word. Since the words in flash are only 14 bits, the math says $3FFF is the largest value possible.

Guess I should've specified. What I really meant was all possible bits set to logic 1.

Do you know this, or are you guessing? I don't see how ORing bits is relevant to the question, but I'm anxious to be informed.

If the erased value of the byte is $ff (assume a byte for the purpose), and you write a $ff, nothing changes. If you write an $f0 next time, the low four bits go to logic 0.
If you try to rewrite $ff, nothing changes, because the only thing that can change a 0 to a 1 is an erasure. Programming changes 1's to 0'.
If you try to rewrite $30, it should change, because you are programming 1's to 0's.
But you're right, I am guessing.
Seems to me that used to be the way people would be able to write patches into UV-EPROM (or PROM for that matter). Changing bytes to all 1's (or 0's) would turn those bytes into NOP's and allow a successive location to be programmed to a JMP to another boot location...something along those lines...

Okay, you've lost me on this one. Please explain: How does disregarding the 2 least significant bits of the address relate to the value stored at that address?

Say you've got an 8 bit address...256 values possible.
If the PIC disregards the bottom 2 bits, it would be addressing 64 possible 'ranges' in 4-byte 'blocks'. Might have something to do with something.

Well, the data sheet seems to disagree. According to it: A read returns 1 word from flash; a write must be done as a block of 4 words; and an erase must be done as a block of 32 words.

Yes, of course, you are correct. I got ahead of myself.
I think in these cases, a read-modify-erase-writeback procedure is needed.
If you want to change one byte, you have to read the whole block that is going to be erased, change the byte you want to change, then write back the block in the 4-byte chunks.

Presumably, one "master" erase of many 32-word blocks would be sufficient for a large number of successive writes.

I think they do that for space reasons. Adding all those extra transistors to 'charge' the cells takes up a lot of space from what I've read about flash memory. Start making the 'blocks' small, and you can't fit as much on a chip. Reading is easy, writing is rough, erasing is hard...comparatively speaking.

[RussMartin]

Do you know this, or are you guessing? I don't see how ORing bits is relevant to the question, but I'm anxious to be informed.

If the erased value of the byte is $ff (assume a byte for the purpose), and you write a $ff, nothing changes. If you write an $f0 next time, the low four bits go to logic 0. If you try to rewrite $ff, nothing changes, because the only thing that can change a 0 to a 1 is an erasure. Programming changes 1's to 0's. If you try to rewrite $30, it should change, because you are programming 1's to 0's. But you're right, I am guessing.

I think I see what you mean, but the OR aspect caught in my throat. Isn't any value (0 or 1) ORd with 1 equal to 1? If $F (decimal 16) is in the "erased" location and $A (decimal 10) is being written, doesn't %1111 OR %1010 yield the same %1111? Doesn't %1111 AND %1010 give (brief fanfare) %1010? Did you mean AND?

Okay, you've lost me on this one. Please explain: How does disregarding the 2 least significant bits of the address relate to the value stored at that address?

Say you've got an 8 bit address...256 values possible. If the PIC disregards the bottom 2 bits, it would be addressing 64 possible 'ranges' in 4-byte 'blocks'. Might have something to do with something.

By the same reasoning, if the device disregards the bottom 5 bits, it would address 'ranges' in 32-byte blocks which gives us a couple of interesting coincidences (4-word write blocks, 32-word erase blocks), but it doesn't answer the questions.

My question 4 was, "How does the write function determine whether the address location has been erased?" It looks as if the answer is, "It doesn't!" So for my question 5, "And what happens if WRITECODE is invoked without a prior erasure?", the answer is "garbage results".

Well, the data sheet seems to disagree. According to it: A read returns 1 word from flash; a write must be done as a block of 4 words; and an erase must be done as a block of 32 words.

Yes, of course, you are correct. I got ahead of myself.
I think in these cases, a read-modify-erase-writeback procedure is needed.
If you want to change one byte, you have to read the whole block that is going to be erased, change the byte you want to change, then write back the block in the 4-byte chunks.

Presumably, one "master" erase of many 32-word blocks would be sufficient for a large number of successive writes.

I think they do that for space reasons. Adding all those extra transistors to 'charge' the cells takes up a lot of space from what I've read about flash memory. Start making the 'blocks' small, and you can't fit as much on a chip. Reading is easy, writing is rough, erasing is hard...comparatively speaking.

With respect to the latter, perhaps speed rather than space is the reason, since the hardware is going to have to accomodate the lower of the two numbers (4), regardless.

As for the former: Fortunately, in my intended application, I don't have to go back and modify an already-written value, so a "read-modify-erase-writeback" scheme won't be necessary (he said, thankful). All I need do is log successive values and--very important--easily find where the logging stopped, which appears as if it can be done by looking for the magic $3FFF after the last value written (the answer to C).

I think/hope I can get by with method A: Assuming prior erasure of a large block of locations, simply WRITECODE to Address and then, next time, WRITECODE to Address+1, and so on ad infinitum--or at least until out of available flash.

[skimask]

Did you mean AND?

Either AND or NOR...one of the two. Either way, in the end, it looks to me like something is broke

By the same reasoning.........."garbage results".

That's the way I'd take it...

All I need do is log successive values and--very important, easily find where the logging stopped, which appears as if it can be done by looking for the magic $3FFF after the last value written (the answer to C).

Unless of course the value that you logged was also $3FFF.
Maybe set aside one or two or twenty-odd bytes for a 'block used' indicator.
Byte0.bit0 = block 0 = words 0 - 15 used
byte0.bit1 = block 1 = words 16-31 used
and so on and so on...
Unless of course you'll never write a $3FFF, in which case you're in there...