Embedding ID in IRQ ROM area

[prwatCCS]

Most 18Fxxx PICS I have used have the reset vector at 0x0000 in ROM, and the IRQ vectors table at 0x0008 and 0x0018

My question is - can I embedded Data at 0x0006 and 0x0007 without
upsetting anything.

For convenience, I want to embed a product ID within the first few bytes of the HEX file.

The following code appears to achieve what I desire, just want to ask if there are any hidden uses of these locations

#build(reset=0x000:0x005, interrupt=0x008:0x0ff)

#rom int 0x0006 = { DEVICE_MODEL_ID >> 8, DEVICE_MODEL_ID }
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK

[temtronic]

From the PIC18F46K22 datasheet, way in the back, of course, but I remembered where...

24.6 ID Locations
Eight memory locations (200000h-200007h) are
designated as ID locations, where the user can store
checksum or other code identification numbers. These
locations are both readable and writable during normal
execution through the TBLRD and TBLWT instructions
or during program/verify. The ID locations can be read
when the device is code-protected.

Others will know if your PIC has this feature....

[prwatCCS]

I know about the ID location features, but I specifically want a form of ID that is embedded within the first few bytes of the binary/hex file.
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK

[Ttelmah]

It depends on exactly which PIC you are using.
Some require one or more extra instructions right at the start of the
code. On some there are extra load instructions that have to be the
first instructions at the start of memory. Then they can have the jump to
the main. This is 'why' the designers decided to leave the extra space
below the interrupt vectors.
You need to look at the listing file for your PIC and see if there are any
such instructions. If not, then you can do this.

You don't need the #build, and what you post could cause issues if
you have a lot of interrupt handlers. If you omit that and just do the
#ROM statement, it should warn if there is an overlap.

[temtronic]

OK, I'm curious..... why the need to embed at the beginning ?

[Ttelmah]

I'd suspect he wants something like a visual inspection of the .hex file
and to be able to look just at the early limes, not go searching further
down.
Historically, though there is not a defined standard for this, a lot of
stuff does accept a line starting with a ';' as a comment, and some
compilers do allow these to be added, so you can have a line like:

; Version 1.01

At the head of the file. It can be quite useful.

[Ttelmah]

I'd suspect he wants something like a visual inspection of the .hex file
and to be able to look just at the early limes, not go searching further
down.
Historically, though there is not a defined standard for this, a lot of
stuff does accept a line starting with a ';' as a comment, and some
compilers do allow these to be added, so you can have a line like:

; Version 1.01

At the head of the file. It can be quite useful.

[Ttelmah]

Actually a quick read shows CCS does support this.

#hexcommentVersion 2.1

Will insert a comment like this, and honestly this is a much clearer and
easier way to do this.
Might be worth considering as an alternative......

However caveat, it remarks that some programmers do not like this.

[prwatCCS]

The reason for wanting to embed a code in the beginning of the binary filewas so that the file can be accepted/rejected early in a transfer process when transmitted over a low bandwidth link.
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK

[Ttelmah]

Do the remark then. You can put this as the first line in the file, and
can make it always exactly the same format. Makes checking it much
easier.