Linker defined objects for checksums ?

[PierreAFD]

Is there a trick to obtain a symbol for a linker computed checksum ?

I put the checksum in a dedicated placement and section, then I define a variable in the placement : result is that I get an overlapping warning at link and at program times.

If I do not declare a variable in the placement, it gets removed, so no reference possible with the __SEG_X_DEF/__SEG_X_REF  mechanism.

Do you have a clean trick ?

If no trick is possible, then Freescale poeple, please, consider this as a feature request.

It would also be nice to be able to obtain references to sections, not only to placements, even if they are not empty.

Regards,

PierreAFD

[CrasyCat]

Hello

The appropriate process to ask for a feature request is to submit an SR though our on-line support web Site.

Click here to submit a service request.

CrasyCat

[PierreAFD]

Must I understand that there is no trick ?

Thanks for the feature request process.

Pierre AFD

[CrasyCat]

Hello

Only way I know to access the data stored there is using a macro reading the content of this specific address.

Something like:

   #define checksum (*((volatile char *) 0x0600))

CrasyCat

[J2MEJediMaster]

Try looking at FAQ-28651, which describes how to insert a serial number into Flash. You might be able to modify this technique to suit your need.

---Tom

[PierreAFD]

Thank you for this advice, but creating a variable to a precise adress is not the problem.

My problem is that I declare a variable that I want to make the linker initialize : a checksum.

In the code :
#pragma CONST_SEG CHECKSUM_PLACE
const int AppliCheckSum;
#pragma CONST_SEG DEFAULT

then in the prm :
CHECKSUM_SECT    =READ_ONLY    0xFBBE    TO    0xFBBF    ;
CHECKSUM_PLACE    INTO    CHECKSUM_SECT    ;

CHECKSUM                       
    CHECKSUM_ENTRY                   
        METHOD_CRC_CCITT               
        OF    READ_ONLY    0x9600    TO    0xFBBD
        INTO    READ_ONLY    0xFBBE    SIZE    2
        UNDEFINED    0xFF           
    END                   
END
=> the linker detects overlapping and warns.

Moreover, the programming tools also warn, but behave differently : P&E programmer puts the checksum value, softec do not !! I am scared that a fix from one will also fix (trash) my code.

A solution would be not to declare a variable in the segment and, at run time, create a pointer using __SEG_X_DEF, but since the section is empty the linker gets rid of it and no __SEG_X_DEF possible.

[CompilerGuru]

This snippet does place two values at the same address, so no surprise different values win for different programmers. Probably they should not program the app at all.

AppliCheckSum does define a 0 value, it does not just give you an address. In C
no objects can have no address, they are always at least one byte. Therefore what you end up with
is that 0xFBBE contains two values, once the initialization value of AppliCheckSum (0) and once the checksum.
I would definitely take the warning seriously and do one of those things:
- access the checksum with the address, just as CrazyCat correctly suggested.
  I see that this means that the C code has to know the 0xFBBE address as well, so addresses are not just in the prm file anymore.
- define a 0 sized object. This is only possible in assembly, not in C.
  Something like (not tested)

  XDEF AppliCheckSum
CHECKSUM_PLACE: SECTION
AppliCheckSum: EQU *
; intentionally empty section

nextSection: SECTION
   ;....

And then in the C code, just use a declaration
extern const int AppliCheckSum;

I personally would just use a "*(const unsigned int*)0xFBBE" in the C code because it is much simpler.
And then document the referral in the prm file for anyone who might change the address in the future.

Preprocessing the prm file would also be a possibility to have a single shared address, but I think this does complicate the setup more than it helps.

Daniel

[PierreAFD]

I agree with all your statments.

The point that made me post is that I have to write the same information (the address) at two places : code and prm.
Since the prm will probably change, I'll have, as  you say, to document and a maintain both informations by hands.
This makes me sad since there are many things possible with the linker, it misses just one tiny thing for me ...

Concerning the "0 value" if you have in code  :

__SEG_END_DEF(CHECKSUM_PLACE);

#pragma CONST_SEG CHECKSUM_PLACE
/* No symbol defined */
#pragma CONST_SEG DEFAULT
const int *PointertoChecksum = __SEG_END_REF(CHECKSUM_PLACE);

and in the prm :
CHECKSUM_SECT    =READ_ONLY    0xFBBC    TO    0xFBBF    ;   
CHECKSUM_PLACE    INTO    CHECKSUM_SECT    ;

Then :
at link : "WARNING L4024: No information available for segment 'CHECKSUM_PLACE'"
at runtime Hiwave indicates :
PointertoChecksum = 0
__SEG_END_CHECKSUM_PLACE = 0, size 0
__SEG_END_CHECKSUM_PLACE[0]=0 size 1 ???????????

If this pointer was well initialized (PointertoChecksum  = 0xFBBF) despite the fact that the CHECKSUM_PLACE is empty, then everything would be fine : no overlapped symbols, and in the code I am sure that I have the real address of my data, whatever happened to the prm.
Perhaps this is due to an optimization ?

Thanks for the 0 sized object trick. I'ts the kind of solution I like, but I cannot implement...

My prm is generated using a spreadsheet.
Maybe if I can launch a macro inside the sheet from command line, I will include the "gear" that my "mechanic" lacks using makefile, this way I will be able to maintain consistency between adresses in code and prm.

Regards,

Pierre