How to tell Keil to write my program to flash at 0x100000 (default in AT91SAM7X256) and to make secondary copy at 0x120000. My program is much smaller than 128kB ;) I don't want to make that manually every time.
I need secondary copy to controll code integrity in SIL application ;)
Do you have any well tested method of self repearing? I thought about this but my boss doesn't trust such methods unles they aren't 100% reliable and predictible... I'm not sure if I can proof that ;)
There are no 100% reliable methods. As long as your boot loader is in flash, you will lose your chip if the boot loader fails.
In the end, you may need to use a flash that has a mask-programmed boot loader, that can perform the comparisons/repair.
You may (!) get away with selecting a chip that has one or more external pins to select boot region. Then you can add external hardware that tries one of multiple boot loader copies, and if you manage to start a boot loader that passes its own self-test, that boot loader can then repair/refresh the contents of one or more application areas and of the other boot loader regions.
In this case, you haven't even written what your requirements are - note that there are special processors intended for very high temperatures. This is very important to think about, since the retention time of the flash is most probably reduced with a factor two for every 10°C increased temperature. The actual scaling factor may depend on the process used to design the chip, but a number of EEPROM and flash technologies have a scaling factor in this region.
Running a chip specified for +70°C at +120°C whould then reduce the retention time with a factor 30, so a 10 year retention time can become 4 months. And since the original retention specification is just an estimated figure where 95% or 99% or 99.9% or whatever of the chips still has the correct information in the flash. But some few units may have shorter retention time for some memory cells - and this variance will also scale with increased/decreased temperature.
Are you sure you can't get away with a CRC to verify code integrity and appropriate behaviour if the actual program doesn't match? What SILevel are we talking about anyway?
Regards Marcus http://www.doulos.com/arm/
For whole application we need at last SIL1 (I suppose it is maximum for our hardware, I'm not expert in that) but if we talk only about software it should be SIL2.
Obviously not familiar with your application, I am assuming that unless availability is at risk (see Per's post), self repair would be completely over the top.
For reasons stated, two copies of the code would hardly be useful to improve reliability. The code to switch between both copies is still a single point of failure.
If you use (potentially available) hardware functions for switching you will likely have to reset between switching, too, putting your system (e.g. I/O) in some state that might not be desirable.
My experience is that engineers working on safety critical applications tend to put a lot of effort into largely ineffective measures to "improve" safety. Ineffective extra code however could pose a greater risk than not having it in the first place.
Before implementing stuff, there must be an analysis why something is believed to contribute to overall system safety.