Problem with MC9S12A512 - HC12 - Memory at FF00-FFFF (Vector Table)

[EmbeddedCoder]

Hi All,

I think there are some discrepancies in the Motorola technical documents for the MC9S12A512, and probably many other variants....

The overview picture of the Memory map shows that memory at location FF00 - FFFF is reserved for the Vector Table.

in the detailed memory map show preceeding this table it states that the memory C000 - FFFF contains 256 bytes at FF80 - FFFF (obviously this doesn't add up...).

This information is echoed in the vector table detailed in section 5 - Resets and interrupts (Table 5.2.1) which details all vectors from FF80 - FFFF.

My assumption is that the many different variants with differing peripherals etc use more or less vector entries. The space that isn't assigned to the vector table (i.e. in the A512 device, space from FF00 - FF7F) doesn't seem to be accessible as "ordinary" rom.

This does all seem obvious in retrospect, but it has been the very annoying and difficult to track source of a intermittent corruption problem in my project!

Could someone please confirm my suspicions (and my sanity) that:

1) The reserved vector table is from memory address FF00 - FFFF, not FF80 - FFFF (i.e. the actual used vectors)?

2) That unused vector space is unusable space.

Many thanks,

Mike.

[EmbeddedCoder]

Many thanks for your very swift reply.

My first assumption was that the vector table that was unused would be available to use as general storage, but I have found that this causes problems....

Specifically, we are using the HC12 linker to generate CRC for all code space (i.e. all 512K in the device), and due to constraints with the Motorola architecture this basically equates to needing many different CRC's (one for each memory Page). During runtime we then check these CRCs - this works really well except....

We have found that generating and running the CRC check across the fixed page residing at C000 to FFFF causes problems, and we have isolated the problem to the memory range FF00 - FF7F (i.e. the unused vector table space). Our sequence of events was:

We created a CRC that spanned memory range C000 to FFFF and this FAILED the runtime check.

We created a CRC that spanned memory range C000 to FEFF and this passed the runtime check.

Then we created a CRC that spanned memory FF80 to FFFF and this passed the runtime check.

Then we created a CRC that spanned memory FF00 to FF7F and this FAILED the runtime check.

All these checks were performed with two linker segments for the C000 fixed page, so the memory should all be accessible:

ROM_C001 which covers C000 to FF7F

and

ISR_TBL which covers FF80 to FFFF

I also discovered that in my full project build some strings were being stored in the area FF00 to FF7F, and I co-incidentally seemed to suffer from intermittent random illegal breakpoint errors - amending the Linker Segment ROM_C001 to cover only C000 to FF00 seemed to solve this problem (although whether this is the actual cause still remains to be proven beyond reasonable doubt).

All of the above led me to the conclusion that the unused vector table space was not useable as normal ROM storage.

Any further light that can be shed on this gratefully received - as we really do need to CRC all memory inside the device, and so if FF00 to FF7F is actually useable, we need to CRC it!!

Thanks,

Mike

[Steve]

I forgot to mention the flash configuration bytes from FF00 to FF0F. Check the contents of the options register at FF0F which may be automatically modified by your debugger/programmer to disable security. If you leave that blank in your s-record your programmer may modify it and this would cause the CRC to fail.

A more remote possibility is that you are enabling the backdoor key access bit and in this case the FF00 to FF07 bytes become unreadable.

Message Edited by Steve on 2007-09-12 04:53 PM

[kef]

Steve,

not just FF00-FF07, but whole flash array gets unreadable when KEYACC gets set. I think it's not what causes CRC to fail. To make it the case, EmbeddedCoder would have to run his code from RAM...

I strongly agree with your suggestion that FF0f (security byte) being automatically modified by debugger.

Best Regards

[EmbeddedCoder]

Hi All,

Yes, it seems to be the debugger that is causing the byte value to change which then alters the CRC value!!

My requirement is to CRC check all memory that could be used for code storage - so as long as I remove the offending portion of code (I will take out the whole section FF00-FF7F) from the linker segments then I should be able to meet the requirements!

It was more confusing to me to understand why this memory section was different from any other, but now I have read the FLASH documentation it all makes sense - sanity is restored!

From a implementation point of view - why did Freescale choose to use memory locations FF00-FF0F for this function, surely it would be better to have placed down in the 00xx's next to other control registers?

Or if you wanted / needed a high address, why not place it right next to the vector table - i.e. FF7F downwards?

And, more seriously, it is very difficult to find the information that locations FF00 - FF0F are reserved, it is mentioned only in the Flash documentation (I know, I should have read ALL the data sheets...) but not at all in the overview document or anywhere else that I can find!

This is quite a big issue, as maybe there are others like me that haven't found this information, and are using the area FF00-FF7F to store Const Data or worse, Code!! Of course, as I found in my project, wierd stuff can then happen (and different stuff when runnning from BDM or standalone!)!

But, in the big scheme of things, a minor gripe - all in all I have found the HCS12 series a very flexible chip!

Thanks,

Mike

[Steve]

Glad you got it going Mike. Thanks for letting us know.
An alternative approach would be to stop the programmer from altering the security byte if you want to have it enabled or change the security byte value in your source.

Those memory locations are a compromise between competing requirements. They can't go beside the other control registers because they have to be in the flash block. So the best place to put them is in an area that is traditionally reserved for other special purposes (to avoid having fragmented code space), which is why they ended up beside the vectors. The reason for not placing them right beside the vectors was to allow compatibility with future devices. We can now say this was a good thing because the S12X devices have vectors that extend into the lower 128 bytes of that page in flash, but those configuration bytes are still in the same place.
Finding the description is easier with the newer parts because they have all of the technical information in the same pdf. But I'll take the comment back to see if we can find a way of making it more obvious.
I'd also like to point you towards the application note library. That's where we focus on providing practical advice on using the parts and I'd always recommend having a quick scan of the website to see if there is something of interest there for you. Keyword searches or the device web page will be the most useful starting points. In this case we have AN2400 which goes into a lot of detail about how the flash works and discusses the use of these configuration bytes.
Hope you continue to find the device flexible enough to meet your needs.
Cheers
Steve

[Steve]

The vectors space is reserved in the sense that it has a specific function (as compared to most of the flash that is general purpose).

The number of vectors used does vary across parts and so the size of the vector space will also vary.

There is nothing special about the flash itself in that range. If the vector table does not fill the 0xFF00 to 0xFFFF space then you can use the flash there for program or data storage. Similarly, if you are not using a particular vector you can also use this as general storage but I would not recommend doing that.

Make sure that your software linker table is set up correctly if you wish to use that space for non-vector storage.

Note that the vector table behaviour is a bit different on the S12X devices.