9S12A32 EEPROM data lost when power cycles

[GaryOlmstead]

Hi --

The subject line pretty much says it all.  I'm certain I am programming the EEPROM (and not registers or RAM, which are located well away from the EEPROM).  I can see the EEPROM data either with the Cyclone Pro, or else via a serial port command to dump the EEPROM (used when Cyclone Pro is disconnected).  While my program is running, the EEPROM data changes only in response to a user command; it is never changed autonomously by the program.  But when I cycle power, whatever data is there has been replaced by garbage.  The garbage is always the same for a given board, but is different for various boards.

I suppose I should add that I am using CodeWarrior and Processor Expert, but I don't see what that would have to do with it.

Any suggestions?

Gary Olmstead

Toucan Technology

Ventura CA

[Lundin]

Out of reset, the eeprom on A32 isn't visible in the memory map. It is mapped between 0x0000 and 0x07FF, hidden beneath the registers and the RAM, which both take precedence. You are likely aware of this since you are writing to the eeprom, which is impossible unless you move it first, through INITEE. Before you write to that register, and/or to INITRM, you can't see the eeprom in the memory map. Perhaps you are simply looking at the out-of-reset values?

Another messy thing worth mentioning is that version 3.x of CW (and possible newer ones too) uses a poor way to solve memory mapping for the debugger. They use a default setting in a "FPP-file" which is stored locally on C:\...\Codewarrior\prog\fpp\. In that file, they assume that every project for a particular S12 derivate on one particular computer always uses the same memory mapping. If you want another one, for example if you actually wish to use the eeprom on your chip, you have to ask Freescale to provide a new FPP file with the correct mapping. All of this is because the debugger downloads some bootloader things at a hardcoded address in the RAM during program download, based on the FPP file.

If you aren't using the CW debugger, you won't however have that problem. It is also possible that Freescale have implemented the memory mapping for the debugger in a better way on newer versions of CW, I don't know.

[GaryOlmstead]

I have INITRG set to 0x00, INITEE set to 0x09, and INITRM set to 0x10, which according to my notes places the registers at 0x00, the EEPROM at 0x0800, and the RAM at 0x1000.

The FPP file would explain why Processor Expert insists that there isn't any memory at locations where I had moved the RAM or EEPROM.  I found the FPP file for the A32.  It puts stuff at 0x1000, but nothing at 0x800.

I am seeing the same problem whether or not I have the debugger attached.  Also, the data is different for different boards.  It looks more like I am seeing RAM, but that doesn't square with my understanding of the INITxx registers.

(...later on...)

I found some other files near the FPP folder. In particular, there are MEM files for each processor.  The file for the A32 shows RAM at 0x800 to 0xfff, which isn't possible (has to be at multiples of 0x1000), and EEPROM at 0x4000, which is possible, and won't interfere with anything else I am doing. 

So, I tried moving the EEPROM to 0x4000, and it works perfectly now.  I can't really explain why, but I can live with that.

Thanks for the help.

Gary Olmstead

Toucan Technology

Ventura CA