This message contains an entire topic ported from a separate forum. The original message and all replies are in this single message. We have seeded this new forum with selected information that we expect will be of value to you as you search for answers to your questions.
Posted: Mon Oct 03, 2005 10:38 am
In our system we are using MC9S12A256B as our main controller. We are using Metrowerks Codewarrior v2.0 for software development and BDM for code download and debug.
There is some critical data, which needs to be stored in internal EEPROM.
During power up data stored in EEPROM is copied back into RAM for further use.
My data is arranged as different variables inside a structure.
For eg:
Code:There is some critical data, which needs to be stored in internal EEPROM.
During power up data stored in EEPROM is copied back into RAM for further use.
My data is arranged as different variables inside a structure.
For eg:
typedef struct { unsigned char UC1; unsigned char UC2; unsigned char UC3; unsigned char UC4; unsigned char UC5; unsigned char UC6; unsigned long UL1; unsigned long UL2; unsigned long UL3; unsigned long UL4; unsigned char UC7; unsigned char UC8; unsigned char UC9; unsigned char UC10; unsigned char UC11; unsigned char UC12; unsigned char UC13[10]; unsigned char UC14[4]; }DATA; The same structure definition is used for instantiation of EEPROM as well as RAM structure variable.
However some variables within the structure do not get stored properly in the EEPROM, especially the character array i.e UC13[10] alongwith some of the unsigned char variables.
But specific observation, which I feel is important is that, storage in the EEPROM for the first time after code loading works fine. But subsequent EEPROM write operations result in improper data storage.
The reason for such behaviour is unknown.
The data is very crucial and we need a solution for this. Your early help may expedite in solving this problem.
EEPROM clk is kept as 192.3 KHz with 40MHz crystel and value of ECLKDIV as 0x5A. The process with which we are writing EEPROM is given below. Here the ram_data values are always correct.
#define BYTE unsigned char #define WORD unsigned short #define LONG unsigned long #define WORD_PROGRAM 0x20 #define CLEAR_CBEIF 0x80 /* Global Variables */ DATA ram_data[4]; DATA eeprom_data[4]; WORD Data_Temp; EEPROM_Write{ /* Local Variables */ WORD *eeprom_Address, *Data_Ptr; for ( Index=0; Index < 4; Index++){ Data_Ptr= (WORD *)& ram_data [Index]; eeprom_Address=(WORD *)& eeprom_data [Index]; for(j=0;j<20;j++) { Data_Temp = *Data_Ptr; *eeprom_Address=Data_Temp; ECMD = WORD_PROGRAM; /*Program the word command*/ ESTAT =CLEAR_CBEIF; /* Clear the CBEIF flag (To launch the Command )*/ while((ESTAT & 0x40)!=0x40);/* Halt till the execution of the command is completed*/ if ((ESTAT & 0x20) == 0x20) /* If PVIOL bit set, clear the PVIOL Bit */ ESTAT = 0x20; if ((ESTAT & 0x10) == 0x10) /* If ACCERR bit set, clear the ACCERR Bit */ ESTAT = 0x10; Data_Ptr++; eeprom_Address++; } } }Posted: Mon Oct 03, 2005 10:57 am
I am not as much of hardware guy but a few questions/recomendations.
1. Isn't 40MHz crystal value to high for a non S12X? I thought most were limited in the 24-30MHz range. I believe the UF32 or NE64 is the only one that goes to 30Mhz that is not an S12X.
2. Have you thought about using a lower frequency crystal along with a PLL? Like 8MHz clocked up to 24MHz via the PLL? Maybe there is noise interfering with your clock frequencywhen it is started.
1. Isn't 40MHz crystal value to high for a non S12X? I thought most were limited in the 24-30MHz range. I believe the UF32 or NE64 is the only one that goes to 30Mhz that is not an S12X.
2. Have you thought about using a lower frequency crystal along with a PLL? Like 8MHz clocked up to 24MHz via the PLL? Maybe there is noise interfering with your clock frequencywhen it is started.
Posted: Mon Oct 03, 2005 1:56 pm
Thanx for an early reply and a valuable suggession.
The problem with us is that the design is already in field and we are tryin to add few more features into it, so it's really very tough decision as many of the things are crystel frequency dependent.
Also with our observations, as we have tried to copy same data simulteneously to a different RAM variable of same structure type, which is always copied perfactly. But within the EEPROM data always the char array UC13[10] gets copied perfactly first time when code is loaded into the controller but for the subsequent writes always that perticular data is garbage. So i can't really understand the reason why would any noise affect any perticular data in a structure only.
I m going to prepare a development board on the similer line as you have suggested to try out. But in the meanwhile if you can tell me whether the procedure followed to write eeprom as i hav mentioned can have any loopholes on the lines of my observations discussed earlier.
The problem with us is that the design is already in field and we are tryin to add few more features into it, so it's really very tough decision as many of the things are crystel frequency dependent.
Also with our observations, as we have tried to copy same data simulteneously to a different RAM variable of same structure type, which is always copied perfactly. But within the EEPROM data always the char array UC13[10] gets copied perfactly first time when code is loaded into the controller but for the subsequent writes always that perticular data is garbage. So i can't really understand the reason why would any noise affect any perticular data in a structure only.
I m going to prepare a development board on the similer line as you have suggested to try out. But in the meanwhile if you can tell me whether the procedure followed to write eeprom as i hav mentioned can have any loopholes on the lines of my observations discussed earlier.
Posted: Thu Oct 06, 2005 11:19 am
Hi,
sorry for the obvious question: Do you erase the EEPROM between writes? Your original post does not mention erasing anywhere...
If you are using an external 40MHz clock source (i.e. active clock generator rather than a crystal) then it is fine. However 40MHz crystal is outside of the device spec which says that the max crystal frequency is 16MHz - table A-15, item 1. This should not impact eeprom operation, but you are out of warranty as far as oscillator start-up and other issues.
sorry for the obvious question: Do you erase the EEPROM between writes? Your original post does not mention erasing anywhere...
If you are using an external 40MHz clock source (i.e. active clock generator rather than a crystal) then it is fine. However 40MHz crystal is outside of the device spec which says that the max crystal frequency is 16MHz - table A-15, item 1. This should not impact eeprom operation, but you are out of warranty as far as oscillator start-up and other issues.
