WRITECODE stores wrong 14-bit word values in FlashMEM

[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

[Darrel Taylor]

Great! Glad it helped.

Makes me wary of using array variables.

Nothing to worry about there. Arrays work perfectly with PBP.
And yes, PBP makes sure the arrays will fit in a BANK of RAM.

The crossing boundary warnings refer to the FLASH memory used by the program. The same area of memory that you are WRITECODEing to.
Arrays can not cause that warning.

Array indexes always start at 0.
So if you have a word array of 3 elements, the index goes from 0 to 2.
It's easy to forget and try to use 1 - 3, but 3 would be outside of the array, probably a RAM location used by another variable.

PBP does not do any "Range Checking". It's up to you to stay within the bounds of the array.

Just about any good program will use arrays in some form or another.
So yup, time to learn ... then play ... then learn more ...
<br>

[rsocor01]

Darrel,
From reading other posts and other documentation (if I understood them correctly) when using arrays in a pic16fxxx and if the program crosses the memory boundary then that would be looking for trouble. In other words, if you are using arrays all over the place in your program, then your program has to fit in one memory block which is ussually not the case. Otherwise, the program won't work properly.
I personally like arrays. They make your program looks neat and more profesional, but also my programs are usually bigger than 2K.

Any comments on this?

Robert