Reading, writing, erasing flash (16F88)

[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...

[RussMartin]

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

Now I get it; you're testing me, right?

Nope, sorry; NOR won't do it, either. To repeat my earlier examples, if $F is the "erased" value in the location and the value $A is to be written:

%1111 OR %1010 returns %1111, so the value in the location is unchanged.

%1111 AND %1010 returns %1010, which is the desired result.

But . . . since the only case when NOR returns 1 is as the product of two 0s:

%1111 NOR %1010 gives %0000 (!)

In fact, anything NORd with $F or $FF or $FFFF is going to be . . . 0!

The winner, still the reigning champion, is AND

[skimask]

Now I get it; you're testing me, right?

No need for that...

The winner, still the reigning champion, is AND

I believe, I've never tried it, but I think you're right. I just didn't have the ambition to do any mental boolean logic.

[RussMartin]

Now I get it; you're testing me, right?

No need for that...

Doggone--I see I kept thinking decimal 10 (%1010) and typing $10 (%10000) instead of $A. How in heck did I manage to do that? I've corrected the posts, but why didn't you catch that and save me from raging embarrassment?

As the Shadow says, "Who knows what evil lurks in the hearts of men?"

I can't believe that absolutely no one else has chimed in on this topic, though.

[rmteo]

....I can't believe that absolutely no one else has chimed in on this topic, though.

Possibly because PIC16's are not really designed to do what you have in mind. Of 93 PIC16's that are listed on MicroCHIP's website, only 6 have self-write capability (which is what allows you to do what you trying to do). OTOH, of 155 PIC18's, 135 of them have self-write. AFAIK, ALL 24-bit core devices (PIC24F/H, dsPIC30 and dsPIC33) have this capability - which I have used on many occassions. You may want to take a look at this App note:
AN1095, Emulating Data EEPROM for PIC18 and PIC24 MCUs and dsPIC DSCs
http://ww1.microchip.com/downloads/e...tes/01095b.pdf

[Charles Linquis]

OK, I'll add my $.02

I have done this - but only with an 18F8722. I used ERASECODE on a 64byte boundary, then issued 32 consecutive word-size WRITECODEs

It worked.

[RussMartin]

Possibly because PIC16's are not really designed to do what you have in mind. Of 93 PIC16's that are listed on MicroCHIP's website, only 6 have self-write capability (which is what allows you to do what you trying to do). OTOH, of 155 PIC18's, 135 of them have self-write. AFAIK, ALL 24-bit core devices (PIC24F/H, dsPIC30 and dsPIC33) have this capability . . .

Thanks for the suggestion. Yes, I am aware that, according to the online chart, only 6 of 99 16-series devices (the '88 and the members of the '88x family) have the capability. The 16F88 was recommended to me by another member of this forum as a good starting point for what I want to attempt since I was looking for a quick alternative to using EEPROM in a '648A.

Charles, good to hear from you again! That's the kind of clear, concise information I appreciate. I'm going to do an empirical test of my trial hypothesis with a similar approach on a 16F88 using a counter and loop now that I have some sort of concept of what's going on "under the hood" and why.

[Darrel Taylor]

Actually, there are 20 16F's that can write to their own flash memory.
But there are 5 different methods, depending on the chip in use.

> I can't believe that absolutely no one else has chimed in on this topic, though.

After your first post, I started making a Flash movie, to show how to write to flash on a 16F88. And before I could even finish the first frame, this thread had already entered the "Confusion Zone", very similar to the "Twilight Zone".

So I decided to expand it to include all the 16F's. Big mistake, takes too long. Should have stuck with the 16F88. Here's one of the frames which shows the different varieties. At that point the flash splits into 6 different explanations. 16F88 is #6.

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2926" /><!-- -->

It'll take too long to finish to be of help to you, and I don't think you are any closer to writing to flash on a 16F88, so I'll try to put it in Words.<hr>

The only thing to really worry about, is that the Write to Flash only occurs when you write to the 4th word in the Block. Writing to the previous 3 words, only places the data in "Holding Registers".

For instance, the following code which attempts to write to the 1st word and read it back ...

FlashAddr  VAR WORD
FlashData  VAR WORD

FlashAddr = $800
FlashData = $123

WRITECODE FlashAddr, FlashData
READCODE  FlashAddr, FlashData

Will return $3FFF in the FlashData variable, because the data was never written.

However, this code ...

FlashAddr = $803
FlashData = $123

WRITECODE FlashAddr, FlashData
READCODE  FlashAddr, FlashData

Would return $123, because it wrote to the 4th word of the block.

If you wanted to only write data to the First address, then you must also write data to the 4th address. If the 4th data is $3FFF then nothing actually gets written to that location.

So this code ...

FlashAddr = $800
FlashData = $123
WRITECODE FlashAddr, FlashData

FlashAddr = $803
FlashData = $3FFF
WRITECODE FlashAddr, FlashData

FlashAddr = $800
READCODE  FlashAddr, FlashData

Will return $123, and only 1 Word has been written to memory.

How do you know if it's the 4th word of the Block?
By the Lowest 2-bits of the address. If they are both 1's then it's the 4th.
Therefore, it's easy to make a subroutine to write a single word anywhere that's free.

WriteFlashWord: ; Set FlashAddr and FlashData before calling (Vars are Destroyed)
    WRITECODE FlashAddr, FlashData
    IF (FlashAddr & %11) != %11 THEN
        FlashAddr = FlashAddr | %11
        FlashData = $3FFF
        WRITECODE FlashAddr, FlashData
    ENDIF
RETURN

The chip should be Erased when it's programmed, so you only need to ERASECODE, if you need to overwrite the data.

HTH,