In my system , if the flash erase not successful , when the software read this block , the software will run away . So how do I know that it did not erase successfully?
Hi,
it has been already discussed, for example here:
https://community.nxp.com/message/872790?commentID=872790#comment-872790
or
Please read this application note for more details:
http://www.nxp.com/files/microcontrollers/doc/app_note/AN5200.pdf
http://www.nxp.com/files/microcontrollers/doc/app_note/AN5200SW.zip
To answer your question "So how do I know that it did not erase successfully?" - read the flash block which is being modified by your application after reset to see if it contains expected data. If exceptions are triggered due to ECC errors (as described in the AN5200) then the flash operation has been (most likely) terminated by unexpected reset and it is necessary to erase the block to recover.
Regards,
Lukas
Hi Lukas, thank you for your reply . Our problem has been confirmed to be caused by erase failure . I notice that , if erase failure, when the device repower, the device sometimes will trigger the interrupt 35 or 36, sometimes will not trigger the interrupt . So I want to know , what should I do , the device will trigger the interrupt always if there are flash error .
Hi Logan,
if you find out that there are ECC errors in the flash block, the only way to recover is to erase the block. There's no other solution.
Regards,
Lukas
Hi Lukas. I know that only way to recover is to erase the block . But , how do I know if there is ECC error with flash ? When the flash is error , if the program read the flash , it sometimes will trigger the interrupt (IRQ 35 or 36), but sometimes will not trigger those interrupt . If the program will always trigger the interrupt when the flash is error , I can erase the flash in the interrupt handler . But the program does not always enter the interrupt , so what should I do that can make the program enter the interrupt always if tere is ECC error with flash ?
Take a look at attached example. It's written for MPC5644A but the principle is the same. In case of double bit ECC error, IVOR1 or IVOR2 is triggered (depending on MSR[EE]) and this exception cannot be masked. ECSM interrupt is triggered only if it is enabled in ECSM module. This depends on you... It is not necessary to enable the interrupt.
What I do in the example: first, it generates EEC double bit error in flash for test purposes. Then let's assume that we use a flash block for data storage and the data are changed in runtime. So, it is good idea to check the block after each reset to see if everything is OK and there are no ECC errors (that means no erase/program operation has been terminated by unexpected reset). So, we can read the block word by word. If exception is triggered, a flag is set in exception handler and then we can erase the flash block to recover it.
Regards,
Lukas
Could you help me ? I need your help very much . Thank you !
But,I do not want to make so much of the segment. In my S12P project , which use CW4.7 . It can define a variable at a specific address by this way " const volatile UINT16 Test_word @ 0xFF0E = 0xFFFC " . Are there a same way which can define a variable at a specific address in CW 2.10 ?
This syntax does not work in CodeWarrior for PowerPC. Just use smaller memory segment in the linker file.
Hi, Lukas. In my sofeware , I use this memory segment :
.__writeback_rom LOAD (0x0000C000) :{}>write_back_ram
#ifdef START_SECTION_WriteBackRom //NVM ROM?
#pragma push
#pragma section all_types ".__writeback_rom" ".__writeback_rom"
#undef START_SECTION_WriteBackRom
#endif
#ifdef STOP_SECTION_WriteBackRom
#pragma pop
#undef STOP_SECTION_WriteBackRom
#endif
#define START_SECTION_WriteBackRom
#include "pragma.h"
volatile UINT8 WriteBakData_Copy_Successful_Flag_NVM = 0;
#define STOP_SECTION_WriteBackRom
#include "pragma.h"
By this method , the variable "WriteBakData_Copy_Successful_Flag_NVM " was defined in RAM. And the flash was allocated a memory for this variable also , and the initial data also exists in the mot file . This is the background for the problems . If this section erase failed , the program will not run at all . So I guess if there are some flash opreate exsit in the start code for the device ? So the flash read in start code will lead the program run away , so that the program can't excute the main function.
Hi Logan,
yes, that's correct. The variable is initialized by startup code. If you change the flash block in runtime (that means there's a risk the erase operation is not successful) then the startup code may crash.
Basically there are two solutions:
- initialize exceptions/interrupts before the data are copied in startup files
- initialize the variable by yourself in main function. So, define it in this way (without init value):
volatile UINT8 WriteBakData_Copy_Successful_Flag_NVM;
and then in main():
WriteBakData_Copy_Successful_Flag_NVM = *(unsigned int*)0x...;
Regards
Lukas
Ok, thank you very much , under your guidance the problem was solved . But I have another qustion , how can I define a variable at a fixed address? For example , let the variable "CalData_Copy_Successful_Flag_NVM " at 0x40004c00 . I want to let this variable to as a flag to indicate whether the flash has error. I use CW2.10 , the device is MPC5604B.