PIC24 question about #ROM and embedding data.

[allenhuffman]

I was curious about placing some data inside our program flash at a specific location. Using examples from the help file, I did this:

[allenhuffman]

Out of curiosity, I ran some tests to help me visualize the HEX file versus program memory. I placed 256 bytes in memory like this (plus another 8 after that):

[Ttelmah]

In the const case, label_address will tell you where the data actually is.
The header is retrieval code to access it. Has been discussed here before.
With #ROM, remember you can only store 3 bytes per word.

[newguy]

Are you actually using them/doing something with them in your test program? Just wondering if perhaps the compiler is optimizing them out if your program doesn't actually use them, or is inconsistent in how it optimizes unused bits away?

[Ttelmah]

Do you have PSV enabled in the code?. Using PSV only two bytes can
be stored in each word.

[jeremiah]

I haven't gone through the assembly personally in a few years, but in the past PCD would insert some code instructions ahead of the table to facilitate the array indexing operation of the data. Data declared with the const keyword can be accessed directly as an array (but not as a pointer) using []. Since the pic24 can only store 24bits at a time with a 4th "0" byte inbetween, the data isn't contiguous and, at least in the past, CCS inserted those instructions so that when you did something like:

char temp = ID1[1];

instead of a pointer + index operation (which it cannot do), it called a small function that would calculate the ROM address based on the index you specified and read data from that ROM location and return it. Basically calling a function "under the hood".

Note that the ROM keyword stores data differently (see the manual for specific descriptions on const vs rom).

Again, I haven't checked in a few years, but I would suspect if you evaluated those bytes at the beginning as instructions it will probably be some special indexing math.

[jeremiah]

One small comment on write_program_memory(). If you call it on an address that is on a "page" boundary (see your datasheet for that number), it will erase the whole page, even if you are only writing a small amount of data. If you have code on that page after your data, it will be erased. Make sure you are using #org to reserve that space and prevent the compiler from putting other things in the space you don't use.

[Ttelmah]

As a comment, the really 'tidy' way to put a block of raw data into your
file, is to use #IMPORT.
Have the data you want to include as raw binary values in a file, then use:

#IMPORT(FILE=.\your.bin, RAW, LOCATION=where_stored, BPI=3)

Then 'where_stored' will tell you where this is. It is stored 3 bytes per
word. If you want the data to go at a specific location then instead have
the data a an Intel hex file containing just the data required and specify
an import range.
Now to read a byte at an index from this data, something like:

[allenhuffman]

Wow, great responses, gang. Thank you.

Earlier this year, we thought we might have need to place a large configuration table in flash. I was experimenting to see how that worked -- i.e., embedding a constant C structure in ROM, versus raw memory that is loaded into a buffer using read_program_memory().

The only Harvard architecture I have used previous to this (this is Harvard, isn't it?) is the AVR found in small Arduinos.

I was also confused between the addresses in the HEX file versus the addresses used by the PIC24.

I am also confused when I read "24-bits stored in a word" since a word to me means 16-bits.

Our existing firmware update routine was hard-coded based on knowing there will be a section (range of memory) for the vector table, program code, and flash config area (haven't gotten to that yet to see what that is for).

When we start using new #ORG statements to place things in other areas, that creates new breaks in the HEX file which our update code doesn't currently handle, so I figured I'd try to learn how this works.

I plan to just detect breaks in the HEX file (any time there is a jump more than 0x10 bytes between lines).

4000 - new segment, goes to PIC 0x2000
4010
4020
4400 - jump, new segment, goes to PIC 0x2200
4410
5000 - jump, new segment, goes to PIC 0x2800
...etc...
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ?

[allenhuffman]

[allenhuffman]

[jeremiah]

[Ttelmah]

The key here is between 'word', and 'instruction word'.

The PIC 24, has a 24bit instruction word. So 24bits are stored in an instruction
word. Sounds as if somebody used this and dropped the 'instruction' when
writing (probably the actual word 'instruction' was implicit in the context or
paragraph), but then taking a quote from this without this implicit context,
makes it seem rather 'odd'....

[allenhuffman]

[allenhuffman]