topic Re: MC9S12DP256 - Root cause for Flash corruption in S12 / MagniV Microcontrollers

MC9S12DP256 - Root cause for Flash corruption

chinni — Tue, 08 May 2007 15:42:41 GMT

Hi ,

we are working for Aerospace domain using the

MC9S12DP256 controller

where we are loading software into flash once and in our code we are performing EEPROM and RAM related operations when fight is in air. at that time Flash corruption is happening. After doing the Root cause analysis what we found was due to code run away problems flash corruption is happening and we added some programs which can initialize the data before writing into flash. But its not exact solution for this problem. So i want to know what could be the reason for flash corruption if the aircraft is in air. How we can avoid them ?

Thanks in advace,

suvarna.

Message Edited by chinni on 2007-05-08 09:43 AM
--
Alban Edit: split thread: new question = new thread + renamed to show part number

Message Edited by Alban on 2007-05-08 12:54 PM

Re: MC9S12DP256 - Root cause for Flash corruption

dwhite — Wed, 09 May 2007 00:14:58 GMT

If you have any code that can write to flash (bootloader, EEPROM emulation, etc.) then I would check VERY carefully for any way it could be executed unintentionally. It would be wise to carefully design this function to prevent unintentional execution.

Did you set FPROT to protect flash?

If so, there should be no way for flash to be corrupted.

If you don't have a bootloader or any other reason to write to flash from your code, you can set this at address 0x7FFF0D to automatically load at powerup. If you have a requirement to write to flash, you can partition and protect code regions from data regions using FPROT, also.

Re: MC9S12DP256 - Root cause for Flash corruption

pp — Thu, 10 May 2007 00:56:06 GMT

Hello,

I've recently had a similar problem with the 9S12A256B. I had a PCB back which was not booting up and
when I read back the device (using P&E BDM Multilink) - all the program code in block 2 (pages $34-$37) was set to 0xFF. The code in Block 3 was still there and all the other pages ($38-$3D) are unused.

I have user config data at address 0x4000-0x6FFF (i.e. page $3E) which I could see was intact.

I also have a bootloader (based on AN2153) residing in the upper area of page $3F. This does make use of the Mass Erase feature and I haven't completely ruled out the possibility of the bootloader being the culprit.

Did you lose all your code, a block or sector(s)?

Cheers,
P.Pearson