WRITECODE stores wrong 14-bit word values in FlashMEM

[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

[Darrel Taylor]

NO! Not true at all.

The size of your program has NO effect on arrays.
Arrays are in RAM, the program is in FLASH.

You may be thinking of the problems that can happen with the BRANCH command if the code is larger than 2K. In which case you need to use BRANCHL.

[BobPigford]

Darrel, et al,

I understand going out of bounds of a dimensioned array, and that arrays start at 0. I believe that my use of array variables was correct, but I will go back and look again. Perhaps I missed something.

I am glad to hear that PBP did not let me down, per se, as array variables are held in RAM and arrays crossing any page boundaries are handled by PBP.

So, I guess I will have to go back and bang out the code with array variables again. It may be a while, but I will report back.

Thanks to all for your help!
Bob Pigford
Newark, DE, USA

[BobPigford]

I am glad to hear that PBP did not let me down, per se, as array variables are held in RAM and arrays crossing any page boundaries are handled by PBP.

Oops. I should not have talked about arrays crossing any boundaries since Darrel reminded me that they are in RAM. Sorry.

Bob