Checksum calculations revisited...

[sebbyBaby]

Am using an mc9s12xdt256, with CodeWarrior IDE 5.9.0

I have created 'bootstrap' code that resides in $E000 to $FFFF, and am placing application

code in $4004 to $D70F, and a secondary interrupt vector table in $D710 - $D7FF.  The

bootstrap checks the CRC of the application area, and compares it with a PRM-calculated

checksum at $4000, and only jumps to the app if it is correct.

The PRM file segment definitions look like:

/* non-banked FLASH */
      ROM_APP_CRC      = READ_ONLY     0x4000 TO   0x4001;
      ROM_APP_ENTRY = READ_ONLY     0x4002 TO   0x4003;
      ROM_4000           = READ_ONLY     0x4004 TO   0xD70F  FILL 0x3F;
      ROM_VEC_TAB   = READ_ONLY     0xD710 TO   0xD7FF  FILL 0x3F;

a) If I use a single checksum entry calculation, from $4004 to $D70F, everything

works fine, and I jump to the app....

b) if I use a single checksum entry calculation anywhere beyond $D70F, it fails.

c) I tried using a two-entry checksum calculation in the PRM file, but - irrespective

of the endpoint of the 2nd stages calculation - it always fails.

Have attached a sample of one of my efforts.

CHECKSUM
    CHECKSUM_ENTRY
    METHOD_CRC16 INIT 0xFFFF POLY 0x1021
    OF READ_ONLY 0x4004 TO 0xD70F
    OF READ_ONLY 0xD710 TO 0xD7F9
    INTO READ_ONLY 0x4000 SIZE 2
    UNDEFINED 0x3F
    END
END

It seems as if the automatically calculated checksum loses its

continuity at the segment change from ROM_4000 to ROM_VEC_TAB.

Is this an accurate asdsessment, and is there possible a workaround

for it?

I'd be very grateful for any assistance in this matter.

Seb

[kef]

Seb,

   UNDEFINED 0x3F

When there's some gap between sections, some undefined addresses, CRC calculator uses UNDEFINED setttng to "fill" missing addresses. I wonder why did you change this to 0x3F? Erased flash state is all ones, or 0xFF for erased byte. Of course CRC should fail on unused locations, since they are 0xFF and CRC calculator assumed 9x3F. Change it back to 0xFF or remove optional UNDEFINED line.

[sebbyBaby]

Hi...

I use 0x3F for undefined areas as it is the opcode for a software interrupt

instruction, which I use to force a reset (processor has definitely gone astray

if it is trying to execute code in an undefined area). I also use it as the filler

byte for the segments.

It does work, in that the CRC is correct up to a point (up to $D709).

Ty for the suggestion, though... there's a couple of things that I can try out to

see what is actually happening, and shall post the results of my investigation.

Is going to be something very subtle, I think..  e.g. I found out that the PRM CRC

calculation does not work with an odd number of bytes (gives an error message!).

It's going to be something in the way that the calculation is performed.

Seb

[kef]

Sorry for noise, I didn't notice FILL 0x3F.

[CompilerGuru]

First, the given version 5.9 is the version of the ide (the build system and editor). The most recent HC12 product version is 5.1 (I think). Are you using a recent version.

Then as the 2 segments are contiguous a single area should be fine. I never used the 2 areas syntax, I actually do not see the benefit of that compared with 2 separate checksums for distinct 2 areas. Either way, that's not your issue.

Did you verify that the content of the flash is indeed correct?

In order to narrow down the reason of the failure I would suggest to use a simpler checksum method (say add) and to narrow down the area which fails as much as possible, preferably to just a byte (or word for a 16 bit checksum). Then I would hope it gets obvious why it is failing...

Daniel

[sebbyBaby]

Hi...

I forgot to check the linker version, sorry...

I too prefer to use the single area syntax; I was thrashing around looking for a

solution.

Flash is correct, in that the CRC works well up to $D70F (DF09, actually).

I hadn't thought of using the 'add' method instead of 'crc-16' to narrow the list

of possibilities; I'll try that, and maybe 'xor-16' as well. That should provide some

clues.

Ty for the suggestion; shall update on my results.

Seb

[CompilerGuru · Accepted solution]

- Did you verify that the flash content is correct other than looking at the checksum result? HIWAVE's load command can for example do a verify.

- The checksum fails as soon as it includes DF0A? What is at DF0A?

  Does a 1 byte add checksum at DF0A fail?

- Which version of the tools are you using?

  In the release notes of the linker 5.0.36 (in MCU10):

  > -  MTWX27784: Fix for an issue where linker calculates incorrect checksum with option -COCC

Daniel

[sebbyBaby]

Hi...

Sorry top be so late replying, but I felt the need to have a

break over Xmas.

I eventually settled on a single entry solution, and got the

thing going...

Your suggestion of using the command line option for the

fix seems to be exactly what I needed; I checked the release

notes, and it seems spot-on.  Have put that on my to-do list

for tidying the software.

Thanks for your help, and hope that you (and the others)  have

a happy new year,

Seb