Reading, writing, erasing flash (16F88)

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)?

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

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

5. #3

---

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

Quote:

---

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.

Quote:

---

Originally Posted by RussMartin

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

Quote:

---

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

Quote:

---

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

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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?

Quote:

---

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

Quote:

---

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.

Quote:

---

Originally Posted by 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 :)

Quote:

---

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

---

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

Quote:

---

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

Quote:

---

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

Quote:

---

Originally Posted by RussMartin

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

---

No need for that...

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by RussMartin

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

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.

Quote:

---

Originally Posted by rmteo

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.

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" /><!-- Attachment 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 ...

Code:

---

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

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

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.

Code:

---

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,

Darrel, much thanks.

As always, you present a lucid, wonderfully informative yet concise solution. I printed a copy of your post and stapled it facing page 32 of the 16F88 data sheet. (My printed copy isn't duplexed.)

I hope you will give thought to finishing the tutorial covering writing to flash for all of the 16F devices and posting it either here or on your own web site. It would be a valuable resource.

And, of course, my apologies for straying into the Confusion Zone. "Who was that masked man?" ;)

If I'd seen your post sooner, I'd have saved myself the frustration (i.e., "learning experience") of my insufficiently informed empirical test . . . which, of course, returned nothing but $3FFF from every location! I did a similar loop with your guidance . . . which, of course, works as if charmed.

This thread put me in some thoughts about updating the firmware from a remote station.

Is it possible to replace the existing firmware of a PIC with new one?

And souldn't there be some kind of bootloader for this purpose?

Ioannis

http://www.etc.ugal.ro/cchiculita/so...bootloader.htm

The problem with this boot loader is that your code is not protected and anyone can copy it.

With Writecode commands, things might be different.

Ioannis

I mentioned it some time back, but I modified a bootloader (MCLoader) such that it was protected.

During startup, the code initially jumps to the start of the bootloader, checks for a special character coming in over the USART, and if it doesn't find it, jumps to a location just below the bootloader where the start vector is stored (it was relocated there by the bootloader routine).

All these vectors are easy to change within the program.

In other words, you can have a password-protected query within your PIC program as to whether the bootloader should be allowed or not. If you say
"YES", then the run-time code patches the program bootloader to run in the normal fashion.
When the program boots up in the normal way, it checks to see if the bootloader is in the "normal" mode. If it is, then it patches the bootloader to jump immediately to the program start vector (thereby disabling the bootloader).

So, the bootloader is normally disabled, and the only way you can get it to work is to tell your program that you want to use the bootloader ON THE NEXT RESET (only) . Your code then patches the bootloader, and invokes @ RESET, The PIC resets and the bootloader runs. Your program loads and when it starts one of the first things it does is check the status of the bootloader (by reading key FLASH locations), and patching them if necessary so that the bootloader won't run again.

I don't know if this was clear, but again, this has been tested to work on an 18F872x family using MCLoader.

If

Hi Charles.

You describe an advanced bootloader that is OK for the most situation, when you are near to the PIC device.

What I really want to investigate if it is doable: To update firmaware where physical contact to the PIC, its reset button or anything else is not an option.

Say that you have built and installed a controller in another town and one day you need to change something in the program. You have DSL connection and a RS232/RS485 to a PC/modem/router.

If you can reach through the Internet the PIC, maybe it is possible to update it too.

Ioannis

There is a lot that can be done when the PIC has the capability to write to its program memory. I would select something more capable/sophisticated than a PIC16 though.

Yes, it is doable. But your bootloader must set up whatever communication method you are using. For example, if you are trying to do this over the internet, the bootloader has to set up the net connection, then wait for a message from the host (hopefully encrypted) before invoking itself.

A bootloader generally has only a very short timeout window when it will accept an outside command to invoke itself (otherwise it would negatively impact the start time of the PIC). Since most bootloaders are set up for RS-232 operation, a very short time (1 second or less) is OK. If you are trying to do a load over the net, you have to deal with a lot more latencies and this time must be extended.

But more of a problem is the possibility of dropped connections. RS-232 is very reliable, but if you are "net-loading" and are halfway through the bootload process and your connection gets broken, are you absolutely certain that you can get it (remotely) restarted? Probably not easy to guarantee when the unit is in China!

There are a couple of ways around this. If you have a big PIC and your code is small and is relocatable (probably not easy with PBP), then your code can reside in the lower half of the device's FLASH space. Your special code-loader could accept the new program and place it in the upper half of FLASH. After loading the new code, your "old" code would then run a CRC on the new code. If it passed, you would then move your start jump vector to point to the beginning of the new code (in the upper half of FLASH) and run. The next time you run the bootloader, it puts the new code in the lower half of FLASH and moves the jump vector again.

With PBP, it is probably easier to do this in a slightly different way; with an external EEPROM. Your bootloader would load the new code into the external device, then run a CRC on it and then copy the code from the EEPROM to the PIC. Doing this shouldn't be too hard.

Please understand that I have not done this myself, I have only pondered how it might be done.

Hi Charles.

Thanks for the reply.

The idea of external EEPROM is nice. Probably must be a fast one, like the RAMTRON FM24C64. Theres is no 10ms delay.

I am very interested in this, and soon I may have some results to post. My main concern is how to lock the code after updating the old firmware.

Ioannis

It doesn't have to be fast - as long as you have control of the program at the "sending" end. Use a pic with at least a couple of hundred bytes of RAM and buffer the incoming data before you do a write to the EEPROM. You would send a buffer full, then pause and wait for the PIC to send a CTS or ACK, then send another buffer... As long as you do it this way, you can write as slowly as you need to in order to write the FLASH.

I do a similar thing now, were I create a 2056 byte buffer (2048 bytes of data + CRC + control) in the RAM of an 18F8722, then send EEPROM data to the PIC in Intel Hex format over a 115K baud serial line, and when it is all received, check the CRC, convert it to binary and do the write to EEPROM. After programming the chip reboots (which destroys the 2056 byte buffer so I can now use the RAM space for my program) and starts with the new configuration. In my case, the 1024 bytes of EEPROM was inside the PIC, but it wouldn't have to be.

This was really designed as a fast way to configure a whole bunch of chips with the same setup, but you could adapt the technique for boot loading.

Hmm, yes you are right on the spped matter.

Thanks for the tips.

One question, why did you use Intel hex format? Is the conversion to and back necessary for your project? It uses abit of MCU power to do that...

Ioannis

I mis-spoke, I actually just used HexAscii (0x0f) = "0" + "F" because I couldn't figure out how to make the VB program I used to receive and send the data handle ASCII zeroes and other odd characters.

OK. Thanks for the details so far.

Ioannis

Quote:

---

Originally Posted by Darrel Taylor

Therefore, it's easy to make a subroutine to write a single word anywhere that's free.

Code:

---

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.

---

This works like a dream!

Thanks, Darrel!