Storing large array in program memory

[nverma]

Hi,

I'm having some trouble storing a very large 1-D array in program memory and not in SRAM. I want to do this so even if the PIC resets, I have access not my array contents. I want the data to be non-volatile and therefore wish to store it in the flash for program memory.

I have done something like this in the past for storing look-up tables and it worked with the const int array[]; method. However, now I wish to overwrite the contents of the array from time to time and still remain non-volatile.

Can I do this in anyway possible? I realized I cannot use the const declaration of the array. This method does not let me over-write the contents, it keep them fixed, which is why it works quite well if it's only a look-up table.

Any suggestions are highly appreciated...

Regards

[FvM]

Generally, it's possible, but there are some points to consider:

1. Limited flash endurance. Microchip specifies minimum cell endurance of 10K write cycles. Depends on your understanding of overwrite the contents of the array from time to time if it's feasible. As my personal criterion, everything that's performed on explicite user interaction should be O.K., automatic actions only if they are timed appropriately (> once a week).

2. Functional limitations. Flash memory blocks have a FLASH_ERASE_SIZE of e.g. 64 bytes with common PIC18 devices. Thus individual variable writes require an additional translation layer, complete array writes are straightforward.

3. Hardware access to flash write and software support. Read the Microchip device's datasheet paragraph Writing to Flash Program Memory and the CCS C description of write_program_memory() and erase_program_memory() for details.

4. Application level aspects. Obviously, a const array in flash must be read only. Write accesses have to go through a different interface.

As an example, with PIC24F devices, EEPROM has to be emulated in program memory. Although a translation layer is required to allow word writes and to minimize the number of erase cycles, it's a smart solution and apparently working in a reliable way.

[nverma]

Thanks for the reply, very helpful information...

Yes i'm keeping points 1 and 2 in mind.

Yes, I did look at the CCS documentation and have come across the write_program_eeprom() and erase_program_eeprom() functions.

However, I do have a concern by just (re)writing specific bytes to a explicit address in memory. I want to store 40,000 bytes, therefore what I am thinking is I start from 0x1FFFF and go back 40,000 addresses and I use this space in program eeprom for my log buffer. But isn't that a bit risky, how do I explicitly tell the compiler to reserve this 40,000 address buffer for me? How do I know it will not over-write any of the buffer with opcode for program code that I develop in the future?

After reading back the program memory, I see that the CCS compiler start at 0x00000 and incrementally starts writing opcode, that's why I have chosen to implement my log buffer at the end of memory. Do you think this is a safe way to 'emulate' an EEPROM in program memory?

[FvM]

The manual clarifies how an #org preprocessor statement can be used to place constant data to a
defined memory location. The compiler doesn't overwrite flash regions reserved by #org.

[nverma]

Thank you, ok that makes a lot of sense....

Now i'm trying to write a byte to an address using the write_program_memory() function using the following code:

[ckielstra]

The second parameter must be an address pointer. Change 'test' to '&test'.

Similar, on reading the data from memory you have to provide a pointer to a buffer for storing the data:

[nverma]

Thank you for your help....I am now able to write & read from the program memory.