9S08DZ32: Does reading from reserved flash locations always return the same values?

[Cantalis]

Hello,

I have the task of implementing a CRC16 checksum calculation into a DZ32. For this controller flash memory starts at 0x7C00. My first approach is to simply take all bytes from 0x7C00 up to and including 0xFFFF for this calculation.

This would include the values read from range 0xFFAE to 0xFFBF (called the 'nonvolatile registers') containing FTRIM, TRIM, NVBACKKEY, NVPROT, NVOPT.

It also contains 'reserved' bytes.

Can I rely on the fact that these reserved bytes always contain the same values when read? Or is there a chance that for a specific controller different values may be read from time to time even if the remaining flash image is completely unchanged? (This would have the unwanted result that the CRC16 value calulated will change from time to time - but a constant is expected)

Best regards

-Roland

[egoodii]

Agreed on 'reserved' locations -- avoid them.  As an aside, may I point to my post:

https://community.freescale.com/message/49009#49009

as a slick/fast way to install & check CRC?  By the way, since that time I have taken to filling 'unused' space with 0x83 (SWI) rather than 0xFF -- longer to program, but vectors cleanly on lost PC, thus:

    ROM                      =  READ_ONLY    0xF000 TO 0xFFAB FILL 0x83; //with SWI

[Cantalis]

Thanks very much for your message.

Since my last writing about this we have finished the project. The filling of unused space with 0x83 was already done by me but it is something which is nearly 'untestable' if you want to check if it has any positive effects (you cannot look inside the silicon during events like power spike, surge, interruption, EMC and ESD events and so on. So what really happens in there if unused memory is filled with 0x83 instead of 0xFF and what it means to the 'total system behaviour' can only be 'assumed').

I have implemented a CRC calculation with a table based version which is much slower than the special 'table-less' version you propose. Only those locations go into my CRC which are definetely contained in our .s19-file used for programming the device. All reserved and special locations (like trim value for oscillator) are excluded from CRC.

[bigmac]

Hello Roland,

Unless each flash location is explicitly determined by the program at compile/link time, I would think it should be excluded from the CRC calculation.  In particular FTRIM and TRIM values would probably be determined at the time of programming the device, and may vary from unit to unit.

I would probably not include any reserved addresses either - nothing is achieved by their inclusion.

Regards,

Mac