MC9S12DP512 EEPROM - How to access all 4K EEPROM ?

[Kupsztal]

Hi there,

I have got a MC9S12DP512  - EEPROM related question.

I've go a project in which I need to use at least 3K of EEPROM. I already use some EEPROM memory, but I need more now. In the description of the IEE1.c, it says : "EEPROM size : 4096 byte", and there are two definitions in IEE1.h :

#define EEPROMStart        0           /* Start address of EEPROM array */
#define EEPROMEnd          4079        /* End address of EEPROM array */

however the prm file shows:

"EEPROM_0400 =  READ_WRITE         0x00000400 TO 0x000007FF;"

Is that correct ? How can I access all 4K of EEPROM memory ?

I would be grateful for any tip/answer. Thx.
Jakub

[CompilerGuru]

The prm file shows the out of reset memory mapping, in
that setup the largest part of the EEPROM is hidden behind the registers (at 0..3FF) or the RAM (>=0x800).
So if you want to use more of the EEPROM, you have to configure the memory map differently, by moving one/multiple of the parts to another address.

Daniel

[Lundin]

The Dx512 has 12k RAM, 4k EEPROM and 1k registers, which you can map anywhere between 0 and 4000h. Ie, 17k to map in a 16k area. So you have to sacrifice either 1k RAM or 1k EEPROM no matter how you do.

[CompilerGuru]

I was under the impression that you can map the EEPROM/Registers and the RAM at a wider area than just in between 0 and 3FFF, but I did not deeply check the HW manuals.

Daniel

[Lundin]

I'm not sure there actually, but if it is possible, you would have to sacrifice flash instead.

[CompilerGuru]

The flash would still be usable in the 0x8000..0xBFFF area are using PPAGE,
just the same way as you have to use all the only banked part of the of the flash (>90%) anyway.

Daniel

[JimDon]

Not sure how are are going to use EEPROM, but it would be possible to temporally move the IO registers away while you read/write EEPROM.
You would probably need to disable interrupts while you do this.

Depending upon how often you access the data in EEPROM, you might also consider moving the hidden EEPROM data to ram at startup.

[Kupsztal]

Hi Guys,
Thanks for all replies. Sorry for delay in my response. I didn't have the opportunity to work on this problem, but I do now.

I simply remapped the PRM  file,

From
RAM_0800  =  READ_WRITE           0x00000800 TO 0x00003FFF;
EEPROM_0400 =  READ_WRITE         0x00000400 TO 0x000007FF;

to
RAM_0800  =  READ_WRITE           0x00000CF1 TO 0x00003FFF;
EEPROM_0400 =  READ_WRITE         0x00000400 TO 0x00000CF0;

and I am using such type of data:

#pragma DATA_SEG EEPROM
   static byte       offset[100][20];
#pragma DATA_SEG DEFAULT

It generally works fine, but I've got some small issue.
When I store the data (one after another) :

for x...
  for y...
      result = IEE1_SetByte( (word) &offset[x][y], (byte)(data) );

The data are being stored correctly until the it reaches the address 0x800 (where RAM used to start). When I store byte in 0x800, it erases 2 bytes on 0x7FC and 0x7FD. Any ideas what happens here and why ?

I will have to do more tests to check if it erases only one word (two bytes) or more.

Thanks for suggestions
Jakub

[Lundin]

Simply changing things in the .prm file only affects the linker, and not the physical storage area. To actually change it, you must write to INITEE and INITRM from inside the program, preferably very early on, out of reset.

And... the Codewarrior debugger might not work properly after that. Sure, it understands that the RAM is moved in runtime, but during download it might get lost, because it downloads some bootloader/debug stuff into the RAM at startup. To solve that problem, you must request a new "FPP" file from Freescale, which goes into Codewarrior\prog\FPP\ and is specific for every S12 derivate. (Therefore Codewarrior does not support different memory mapping for multiple projects using the same S12 derivate.) And if you are using the Codewarrior .cmd files for the debugger, you will have to alter them as well.

This is all really messy, undocumented and hard to solve. If you ever run into these kind of problems, the best solution is to simply get another debugger.

[JimDon]

I haven't tried this either, but as long as we are speculating.

For one thing, out of reset everything will be "normal", so there should not be a problem burning flash.
Nor should you need to change the fpp files.
Presumably, you are going to write EEPROM, so that is not an issue.
You will have to write the registers yourself to remap things.

The abs file is generated based upon the prm, so the debugger should "know" where the code is and where variables are.

If you DID did to change the fpp file, you could in the .ini file add:
NV_PARAMETER_FILE=C:\mydir\my.fpp
After you cut paste and hack them.

As for other debuggers, the only other on I've used is NOICE, and all it knows is what the abs file tells it, just like HIWAVE, so I am not sure how it would do any better.

I am eager to hear about another debugger that may do better.

From the help file:
"However, if the relocation is performed by the application itself, the usage of the FPP relocation is useless, as the programming is performed with the default location of the RAM. "




Message Edited by JimDon on 2007-09-04 12:24 PM