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 ;)
I am not sure there aren't better ways, but you can try to create 2 scatter files associated with 2 different targets.
Better ways of making secondary copy or checking code integrity ;)
What file uses keil to flash CPU? Hex? Bin? If one of them I can write simple application which will make the job. But I doubt Keil use hex or bin to flash :(
Both :-) I think Keil uses the ELF output for flashing. I suppose you could generate HEX or binary, manipulate the image and use a different flashing tool. As for checking code integrity, wouldn't checksumming be more appropriate?
Multiple binaries are what you often use in high-temperature applications, where there is a high probability that the high temperature will result in bit errors in the flash image. You then constantly scans your multiple images (more than two) to try to repair detected flash errors.
With just two images, you can detect a difference. But you need MD5, SHA160 or similar to see which one that is defect - and with bad luck, buth may be defect.
So, the next step is the need for block-level MD5, so that you can see exactly which blocks that has problems.
But if the goal isn't to repair, but just to detect a problem, then you don't need two binaries. It is enough to have a checksum or message digest of some type. Normally you teach the software that the message digest 0xffffffffffffffffffffffff means that you are running with the debugger and doesn't have any MD5 to compare with. Any other value means that the binary should regularly recompute and compare.
This allows you to run the normal debugger when developing, and then run a post-processor program on the bin or hex file to create the production binaries. You normally complement the checksum/message digest with a timestamp, a version number, and a magic type identifier allowing a boot loader to present information about the found binary, and to block updates with binaries intended for another project or for a different hardware revision.
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.