Flash data lost

[gexiaocheng]

Hi,guys!

The use of MC9S12C64 is as a ECU controller, a few days ago, there is a problem: at first, the engine works well, but after the vehicle has drivered 3000km,the code which is in  the MCU is erased directly, the specific address is 0x6000 to 0x6400, the code of other regional is no problem, so is there anybody can tell me what is the cause?

Any help offered would be greatly appreciated.

[kef]

Are you using S12C flash for data EEPROM emulation? Then most likely you have a bug in emulation routines.

[gexiaocheng]

Yes,your inference is right, I am using S12C flash for data EEPROM emulation.

But the address of flash for data EEPROM emulation is 0xC000~0xC400, and the command for erase the flash is just sector erase (FCMD=0x40), but the address which the data was lost is 0x6000~0x6400.

Other thing is the data is correct in the flash when we test it on the Demo board and routines is running well.

So can you give me some suggestion to repeat this phenomenon or other help? Thank you!

[RadekS]

First point (How): From you description it seems that data on address 0x6000 to 0x6400 was erased accidentally by your software. You mentioned that you use EEPROM emulation at 0xC000~0xC400. I suppose that probably initial code for EEPROM emulation was executed however with wrong parameter. There is too many similarities (0x400 data area, 0xC=0b1100, 0x6=0b0110).

Could you please check your software if there is somewhere used bit shift for address of erased area?

Second point (Why): I suppose that erase code was executed accidentally. Typical reasons where CPU gets lost are:

1. Unexpected interrupt
2. Stack overflow

I would like to recommend specify interrupt function for every interrupt source even if this function contains just single NOP or BGND instruction. Default values of unused reset vectors (0xFFFF) are not valid and MCU will work unpredictable in case of unexpected interrupt. Unfortunately S12C doesn’t have illegal address reset.

Could you please check your stack placement and variables which are placed under stack (if there are any)?

Anyway investigating will be probably difficult.

[gexiaocheng]

I am very glad to see your replies. and thank you very much for everybody. :smileyhappy:

One thing need to confirm is  just the MCU lost the code on address 0x6000 to 0x6400, we don't know the specific reason ,we just guess the possible reason is the  0x6000~0x6400 flash was erased accidentally when we used S12C flash for data EEPROM emulation.

According to your analysis, I do check the software, and  the result as follows:

1. The function which is for flash erase, got the address by taking pointer of the array, and it desn't use bit shift. The function is like that:

fburner ( (unsigned int *)&InputEepromInFlashRecorded, (unsigned int *)&InputEepromInRam, sizeof(InputEepromInFlashRecorded)/2);

"InputEepromInFlashRecorded" is an array which defined by myself.

2. Unexpected interrput.

Now we used 13 interrupts, they are ：System Reset，Real Time Interrupt，Standard Timer Channel 0~7，Standard Timer Overflow，SCI，PortP Interrupt. Other unimplemented Interrupts have an same interrupt function. The function is like that:

__interrupt void unimplementISR( void )

{

  return;

}

So I think unexpected interrupt will not cause flash erase.

Another thing: I changed the highest priority interrupt which is standard timer channal 0 interrupt( HPRIO=0xEE;).

3. Stack overflow

Now stack size is 0x100 bytes.and  I didn't clear the I-bit and other interrupts were forbid during the routines was running in any interrupt. So I think stack overflow is almost impossible, however, I haven't test it, I am not sure.

The variables which are placed under stack are static variables, and these variables are used for SCI communication and other control logic, there is no relationship with flash address.

4. Flash Security

Now I didn't used flash security function( $FF0F=0xFE ); my colleage told me the flash was erased maybe by BKGD port for electrical noise. If we used this function of flash security, all flash memory will be protect and flash was erased by BKGD will be prevented. So how do you think about it?

According to the trouble shooting rules, I think now the urgent thing is how to repeat this issue, then we can find the real  cause.

Thank you again for all of you!

[kef]

Security disables reads over BDM, but doesn't disable writes to registers, so it doesn't disable flash erase. Instead you should use flash write protection.

[kef]

Well, if it's not the problem in emulation routines, then maybe other part of code by mistake writes to flash status register or something like that. I recommend you to move your data area to 0x4000.. and use flash write protection. I like it. On S12C it is possible to have initially only bootloader write protected, and then extend write protection to lower addresses keeping data area at 0x4000 not write protected. Just a single write to FPROT and no worry about accidental code erasure. Of course real cause of issue still should be investigated.