Reading, writing, erasing flash (16F88)


Closed Thread
Results 1 to 27 of 27
  1. #1
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263

    Question 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)?
    Last edited by RussMartin; - 23rd October 2008 at 03:00.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  2. #2
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

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

  3. #3
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by skimask View Post
    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.
    Last edited by RussMartin; - 23rd October 2008 at 05:33.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  4. #4
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by RussMartin View Post
    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.

  5. #5
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Default

    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.
    Last edited by RussMartin; - 23rd October 2008 at 23:35.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  6. #6
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by RussMartin View Post
    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...

  7. #7
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Default

    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
    Last edited by RussMartin; - 23rd October 2008 at 23:36.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  8. #8
    skimask's Avatar
    skimask Guest


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by RussMartin View Post
    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.

  9. #9
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Default

    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.
    Last edited by RussMartin; - 23rd October 2008 at 23:58.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  10. #10
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by RussMartin View Post
    ....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

  11. #11
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

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

  12. #12
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by rmteo View Post

    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.
    Last edited by RussMartin; - 24th October 2008 at 07:22.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  13. #13
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default

    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" /><!-- Name:  FlashChips.JPG
Views: 1178
Size:  34.7 KB -->

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

  14. #14
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Thumbs up

    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.
    Last edited by RussMartin; - 24th October 2008 at 20:44.
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

  15. #15
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    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

  16. #16
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

  17. #17
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    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

  18. #18
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

    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
    Charles Linquist

  19. #19
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    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

  20. #20
    Join Date
    May 2007
    Posts
    604


    Did you find this post helpful? Yes | No

    Default

    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.

  21. #21
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

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

  22. #22
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    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

  23. #23
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

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

  24. #24
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    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

  25. #25
    Join Date
    Sep 2005
    Location
    Campbell, CA
    Posts
    1,107


    Did you find this post helpful? Yes | No

    Default

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

  26. #26
    Join Date
    Nov 2003
    Location
    Greece
    Posts
    3,795


    Did you find this post helpful? Yes | No

    Default

    OK. Thanks for the details so far.

    Ioannis

  27. #27
    Join Date
    Aug 2006
    Location
    Omaha, Nebraska USA
    Posts
    263


    Did you find this post helpful? Yes | No

    Smile

    Quote Originally Posted by Darrel Taylor View Post
    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!
    Russ
    N0EVC, xWB6ONT, xWN6ONT

    "Easy to use" is easy to say.

Similar Threads

  1. Writing & Reading to iButton EEPROM
    By crhomberg in forum Code Examples
    Replies: 2
    Last Post: - 6th October 2008, 20:40
  2. Writing and reading to a 24LC1025
    By Angus Anderson in forum mel PIC BASIC Pro
    Replies: 6
    Last Post: - 20th April 2007, 12:49
  3. reading, writing, and displaying from eeprom
    By Rhatidbwoy in forum mel PIC BASIC Pro
    Replies: 7
    Last Post: - 12th January 2006, 23:05
  4. 16F88 reading Analog Input
    By thunderstrike44 in forum mel PIC BASIC Pro
    Replies: 2
    Last Post: - 30th August 2004, 23:41
  5. Writing / Reading EEPROM 24LC256 Problem
    By schmoddel in forum mel PIC BASIC Pro
    Replies: 4
    Last Post: - 27th February 2004, 19:55

Members who have read this thread : 1

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts