About MC9S12B64 EEPROM Start address

[Zeke]

Hi,
I use 9S12B64 in single chip mode, and EEPROM initialization setting INITEE = 0x09.
I read "HCS12 B-Family Product Brief", the figure 5 "MC9S12Bx64 User Configurable Memory Map", EEPROM start address is seem to be 0xC00 (half of 2K EEPROM address 0x800 ~ 0xFFF). But I read all variables from EEPROM don't match original variables. And I try many ways to find out what problem it is. Finally, I found out EEPROM address is 0x400. I still don't know why EEPROM address is 0x400? Somebody can tell me what informations I lose, and thanks.

Compiler : Cosmic CX12
Chip : MC9S12B64
Question : EEPROM Start address



Zeke

[Zeke]

To Mike:
Yes, your points are right and I agree with that. It is must to be done before your project going. In my case, I use DG256 for development and B64 for product. Code and constant sections must match between DG256 and B64. So I have figured out all section, include address and size(all memory block size base on B64). And make sure these sections size not overlap or overlay. However, I follow your list to check my code and make sure it again.

Thank you for your reply to clear that I may make a mistake.


To Lundin:
I have read B firmly date sheet,too... Two memory map in B firmly date sheet P29 and product brief P10 confused me. Which is correct?
Before using B64, I develop on DG256 and DG128. EEPROM address is 0x800 ~ 0xFFF for DG128, 0xC00 ~ 0xFFF for D64. Maybe it is wrong that I think B firmly EEPROM are compatible to D firmly. But after testing, it looks like B firmly date sheet is right.

Thank you.


Zeke

[Lundin]

I know for certain that the EEPROM is placed at address 0x0000 out of reset for D64, Dx128 and Dx256. Which means that the whole D family is likely the same and that it's behaving in the same way as the B family, making them compatible.

Freescale has various places in the manuals / app notes where they -recommend- a certain memory map. Whether or not you wish to set it up according to their recommendation is up to you. The reason Freescale didn't give us a sane memory map out of reset is because of compability issues with Dx256 (and larger), where you must map 1k registers, 4k EEPROM and 12k RAM = 17k, into 16k of memory.

If you think the figure on p29 is confusing, take a closer look at it and read "The address does not show the map after reset, but a useful map. After reset the map is:.." followed by the values out of reset.

And you can find the same story in the register description of INITEE, INITRM and INITRG.

[Zeke]

Ah........E388 P14 "Table 11. Re-mapping to Locate the Registers Block in the Direct Page"

It gives me wrong information about B64 EEPROM address.

[Lundin]

A product brief? Read the manual.

Device user guide p29
"Figure 1-2 MC9S12B128 Memory Map out of Reset"

The EEPROM is mapped to address 0x0000 out of reset.

Since the registers take precedence and they take 400h bytes of space, you will find the part of the EEPROM that isn't hidden behind the registers at address 0x0400.

However, if you write 0x09 to INITEE, the EEPROM will end up at 0x0800.

[mke_et]

Well, first off let me say that I'm not familiar with that chip variant, so I'd have to actually go look up the specs on the B64.  But I can point out a few things you can check.

Have you run code and stopped it to read the registers to find out where things end up getting placed?  That's one of the first things I would do to find out if the default setups weren't where or what I expected.  Then I'd try to figure out where in the code they were being set.

In my case, I didn't want default setups, and I was running 100% assembler anyway, so I threw out all the code that the project tried to start with and I do everything myself.  I know, I'm hard core assembler.  It's like digging a fence post hole with a spoon.  It takes a long time but I have absolute control of the dirt...

Ok, so what do you need to know about things.

Check the 'size' of any of the 'pieces/parts' that you're going to move around.  This can be tricky, as you're going to use the size to figure out how to 'lay them in' so to speak.  If you have a section of EEPROM that goes in with 2K of overlay, you can pretty much be certain that it has to go modulo 2K for it's start location.  That is, it cannot 'straddle' a memory location that is the size of the block.  Also, if I'm not mistaken, there were one or two parts that the granularity of where you could place the region was BIGGER than the size you could use.  (I'm not sure if that was just an errata on early parts or what)

The other thing you need to check is priority of the regions.  For example, if you try to overlay two things at the same address, who wins?  Well, the winner is pretty well defined if you read through the spec sheets, and you can use that to your advantage.  If you know one region will be visible over another region that you don't need the whole space for, you can use it to 'pack' your memory map to make other things easier to fit.  That also can be a trick to use when you develop on one part but ship on another.  In my case, I developed on a 9S12DP256 but shipped a product on a 9S12DG128 or other 128 variant.  When I developed on the 256 part, I just let the map overlap parts and didn't care.  As long as I could get at what I needed to when debugging code. 

Mike

(the poster formerly known as mke_et)