Reading, writing, erasing flash (16F88)

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

[RussMartin]

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.

[Ioannis]

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

[rmteo]

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

[Ioannis]

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

[Charles Linquis]

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

[RussMartin]

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.

This works like a dream!

Thanks, Darrel!