On the 16F87x and 16F87xA series, ERASECODE will not work. In fact, if you try to use the statement, it will generate an error since there isn't a bit called "FREE" in the EECON1 register.
And yes, PBP takes care of most of the details. But there are still some things the user needs to understand first.
As you've already mentioned, with the A version of these chips, you have to write in blocks of 4-words at a time.
Not just any 4 words, they have to be aligned to a physical Flash boundary.
<table><tr><td><img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3294&stc=1&d=123862608 0" /></td><td valign=top>Since you want up to 2k of space, I assume you're starting at the beginning of Flash Page 3 ($1800).
Blocks always start at the address where the 2 lsb's = 0. So in this case the first block is at $1800.
From there you need to write 4-words consecutively. When it does
WRITECODE on 1803 (the 4th word), the contents of the Block will be erased automatically, and the new data will be written.
While erasing, the CPU will "Halt" for approx. 4mS. The OSC is still running, Timers are counting (if used) and the USART will continue receiving data. But SERIN(2) or DEBUGIN cannot receive data during that time. It's easy to miss data if not using the USART.<HR>
If you are attempting to READCODE the word that was just WRITECODEd, for verification ... unless all 4 words of that block have been written, you will not get the expected value back.
<hr>
If you are using
Interrupts in your program, they should be
disabled globally before writing to FLASH. If an interrupt occurs in the middle of a WRITECODE statement, the procedure can be disrupted and no write will happen, or incorrect data may be written.</td></tr></table>
I could probably ramble on for awhile, so if that doesn't point you in a direction, perhaps a peek at the code might shed new light.
<!--
Attachment 3294 -->
Bookmarks