int8 ROM array

[Torello]

Hi,

In a pretty large program ~75K I use this

[asmboy]

see
http://www.ccsinfo.com/forum/viewtopic.php?t=26245

especially item #4

[Ttelmah]

What chip?.
I see AsmBoy raises the same question, and a few others.

However, it does get complex, since some things use byte addresses, and some int16...

Big problem though is just how complex writing the bytes is going to be.
Remember on larger devices, the program memory is always organised as large pages. You have to erase an entire page.
So modifying the values, becomes:
Read the entire page to RAM
Modify the bytes in RAM, leaving the others unchanged.
Erase the whole page, and write the page back.

Now the compiler will automatically erase a page, if you write to the first byte of the page. So it'll be enormously easier if these values are placed at the start of a page containing nothing else than the 'constant' values. Look at #locating them. However also remember that on most of these chips the very top of memory contains configuration data, so locate them a page 'clear' of this data.

read_program_eeprom, returns the entire word at the address.

Beware also that a pointer, may not actually be the physical address. Use label_address.

[Torello]

Pic18LF4685;

Found a solution that works.

[Ttelmah]

OK. Not a terribly large chip then (was thinking of things like PIC24's and up), so doesn't have the problem of config data at the top of memory.
Sensible solution, and now means you know exactly where things are, and how much you have to erase.

[asmboy]

and i have to ask:
how often do you plan to rewrite the prog memory?

because rewriting it even ONCE makes me anxious-

especially since without a fall-back fail safe design approach
- any mission critical function for the MCU could be in doubt.

i've perhaps been where you are and
greatly prefer a high-rel external SPI eeprom,
with recorded check values and a
safety fallback in the main MCU code should read back error be detected.

I am involved with medical electronics and
in short i would never do what you want to do.

[Torello]

Hi Asmboy,

Thanks for the warning. I do agree, but make a pragmatic exception. The bootmark I use to distinguish a plain MCLR / power reboot or the same after a firmware update.
In latter situation I need to set a lot of variables with default values.
So I flash program the bootmark 0x0000 At at Mclr or Power boot I read this value. Anything but 0xEBEB will trigger an default init.
After successful initialization I write this 0xEBEB once

The other variable is just a Quick test thing that will be removed again.

Ttelmah also thanks!
_________________
Regards, Edwin. PCWHD v5.114

[asmboy]

[Ttelmah]

In which case, you should move the bootmark.

Thing to remember is that the standard routines, erase the whole page, when you write to the first byte in the page.
You need to:
1) Erase page.
2) Write all the data, except the bootmark.
3) Verify the data.
4) Now write the bootmark.

Having the Bootmark at the start of the page makes this awkward. Better to place it as the last word in the page.

[Torello]

But it is just a single bootmark (ak. flag). The initialization data self in not in this page. The design pattern you describe I more a less use for data-structures stored in eeprom. Only there the actual location is of the flag is not important as eeprom can be written random.

I still think my initial problem might be a CCS bug. I'll write a small test program to see if it occurs there also. If it does I submit it.
_________________
Regards, Edwin. PCWHD v5.114

[Ttelmah]

The point is that you are writing a 'block' of configuration data.
The easiest way to do this (and more efficient on time, since it does a block write - remember that the chip is completely disable while every EEPROM write if being performed), is to use the 'write_program_memory' function. This _automatically erases when you write to the first byte of a page_.

So if you write all your config data, starting at the beginning of the page, a single page write operation erases, and writes all the data (instead of having to do separate writes for each word of the data).
You can then read this data, and if it is correct perform one 'write_program_eeprom' function to set the flag.

If the flag is at the start of the page, you have to do a separate erase, then write all the configuration word at a time, using separate writes, then perform the verify, and then go back and write the flag.

A lot slower, and more likely to cause problems....

[Torello]

WOW!

Back to the original problem. The write_program_eeprom(BootMark) has been in my code for many years. And I know it has been working.

Wrote a little test program and compiled it with old and new versions.
The oldest I have got available is 4.136
With this version it compiles OK !!
With version 5.020, 5.026, 5.042 it compiles WRONG!

I'm going to submit it to CCS.

[Torello]

Pfieuw, this makes my Friday.
The "field" version of my firmware is far smaller then the test / debug version.

It does reach the wrongly written memory address 0x0FFFE
_________________
Regards, Edwin. PCWHD v5.114

[Torello]

Update: The bug is acknowledged by CCS: