WRITECODE stores wrong 14-bit word values in FlashMEM

[BobPigford]

Hello!

I am using WRITECODE and READCODE at run time in a PIC16F876A. I send in a series of 70 or more words from my PC (none larger than a 14 bit value) and WRITECODE them into upper FlashRAM sequential addresses (not overwriting program memory).

But when I later READCODE the values from memory, some (about 20%) of the values are wrong. The errors do not follow any particular pattern in the memory sequence that I can see.

I know the 14-bit values are being received correctly by the PIC because I send them back out to an LCD for view prior to the WRITECODE instruction. I have confirmed the errors by sending the READCODE values back to the PC and compared them with what was sent.

The PIC16F876A data sheet talks about writing in blocks of 4 words, not crossing page boundaries, and that a write is really an erase-then-write operation, but I thought that PBP took care of all that for WRITECODE and READCODE.

I will be glad to post the code here if needed, but before doing that I need to ask a basic question:

Am I supposed to use ERASECODE before using WRITECODE on a PIC16F876A?

I would appreciate any guidance you can give on this.

Thank you,
Bob Pigford
Newark, Delaware

[peterdeco1]

Hi Bob. I'm not an expert at this but I use 16F872 & '873 a lot. Instead of READCODE and WRITECODE, try using READ and WRITE. I believe you are writing to program memory space instead of eeprom.

[Archangel]

Hi Bob,
Check these 2 links from Melanie:
http://www.picbasic.co.uk/forum/showthread.php?t=137
http://www.picbasic.co.uk/forum/showthread.php?t=545
Should be something in there that is helpful.

[BobPigford]

Hi Bob. I'm not an expert at this but I use 16F872 & '873 a lot. Instead of READCODE and WRITECODE, try using READ and WRITE. I believe you are writing to program memory space instead of eeprom.

To: Peterdeco1
Thanks for the suggestion, but I do want to write to program RAM (flash RAM) because the EEPROM space will be too small for the 2000 words I want to be able to store eventually.

To: Joe S.
I appreciate those links and I have read and re-read the good info from Melanie several times. She still does not clarify the need for a ERASECODE prior to WRITECODE, though. In fact, after previous readings of her posts, I had assumed that I needed just WRITECODE and READCODE and that PBP took care of all the details.

Please send more suggestions. I appreciate all help!
Bob

[Darrel Taylor]

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.

<!-- -->

[flotulopex]

Hello Bob,

Even if very risky (and surely very amateur wise), I'm using the program memory in one of my gadgets for months now using the WRITECODE command.

At the start, I used ERASECODE prior to WRITECODE according to this statement:
<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=3296&stc=1&d=123866553 2">

After lots of tests, I can say that ERASECODE is not making any difference (if not used, I save some memory space).

The only thing I'm sure about is, that WRITECODE will "rewrite" four (4) words at the time (!!!).

[BobPigford]

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

Thank you all!

Ahhh. I see. I will now:
1) Start my WRITECODE at an appropriate address (block start boundary).
2) Make sure that the last of my many consecutive WRITECODE instructions are padded with enough additional WRITECODE instructions to fill the last block completely.
3) If I go back and try to WRITECODE over a previously written address, I must know where it was in that block of addresses, then re-write the adjacent values for a total of 4 WRITECODE instructions to fill that block again.

I will report back!

Thanks again.
Bob

[BobPigford]

Hello all!

Following Darrel Taylor's excellent instructions, I was careful to WRITECODE to 4 word (complete) blocks starting at $1800 (or any other address where the two LSBs are 0's). I still saw wrong stored values. Every 6th address (and a few others) had an error ... VERY strange behavior.

I had been using 12 WORD sized array variables of 3 elements each, stuffing the last 2 variables of each array into memory (WRITECODE). Suspecting that array variables were the culprits, I changed to 36 individual WORD variables along with all the repetitive code required. NOW IT WORKS!

The PBP manual (pg 25) says clearly that "The compiler will assure that arrays, as well as simple variables, will fit in memory before successfully compiling."

My code is about 4100 WORDs in size. It compiled just fine, albiet showing three notes at the bottom of the screen that code page boundaries were being crossed. I had assumed that since the code compiled just fine, that the 3 warnings pertained to the overall size of my code. BUT, perhaps those were warnings that arrays would not work.

BUT why did it still compile OK? Did the PBP compiler let me down?

Makes me wary of using array variables. I need to learn more about this in the future!

Thanks again to all for your help!
Bob Pigford
Newark, Delaware