Bootloader code for safety device

[imranaftab]

Hi ST,

We are making product targeting SIL3 safety by using STL library. 

So, I have few doubts :-

1. Is it recommended to have a bootloader in a safety grade product?

2. If Yes, then how can I proceed? 

3. In normal way bootloader code should be written or with all safety handling as recommended for SIl 3 application?

4. And If I start writing as normal bootloader then as I use 

Flash_Write_Data(ADDR_FLASH_PAGE_63, (uint32_t*)&cardConfigArray_write, 2);. Then STL flash fail error comes even this code is in condition not at all executed.I am using this to jump into bootloader by raising a flag method.

5. Any other point should I keep in mind while writing this bootloader? 

[Tesla DeLorean]

Can presumably used staged execution, where you authenticate the loader image, then authenticate the application image before transferring control. If the authentication process is sufficiently complex and one-way, it would tend to test the viability of the processor, memory and code execution in the process, say CRC, or SHA256 into SECP192R1 against a public key.

If "your" code can't write to flash, you should perhaps be booting the device into the ROM's loader and use that, or stage something in RAM.

The device isn't going to be viable during the update process.

If the FLASH KEYS to unlock the peripheral can't exist anywhere within the MCU memory space (FLASH, or ROM), you might need to get ST to make a different loader they program into System Memory, or deliver them with System Memory unwritten.

[Mikk Leini]

Let's not mix up safety and security, even if they have similarities and both are important.
I can speak from automotive safety perspective, but it has the same origin. I must say that you get the answers from comprehensive development processes that you need to follow, because otherwise it won't be a safety product anyway, but I understand the need to start software development from somewhere.

Part of the process is analysis (e.g. FMEA) on what would compromise safety when there is a bootloader or there is not a bootloader. Or if bootloader is not functioning, functioning improperly or functioning when it should not function. These questions in mind, I'll give some example (because you cannot rely on this information alone) answers.

 

1. Generally yes. Because if application is faulty and you cannot update it then you usually have even bigger problem. Whether the bootloader shall have self-updating option can be debated.

2. I'll answer in 5th.

3. If bootloader runs on the same hardware (HW) as application then it theoretically can activate the HW that could cause harm. Unless you want to make SIL3 level bootloader, which you very likely don't want, you need to do safety function decomposition. Basically you need to prove that you have a system where bootloader cannot cause harm. Obviously it shouldn't contain any application specific code, it should be reviewed, tested, etc., but you may want to setup some active protection for random faults or bugs. E.g. the HW that the application controls might have a specific initialization or keep-alive sequence that is unlikely to occur randomly. If you use two-stage bootloader you may setup memory protection unit (MPU) in first stage to let only the application access specific peripherals.
4. Sorry, I don't understand the question.

5. Couple of more suggestions:
a) You may want to use always enabled (from option bytes) watchdog. If bootloader or application are so faulty that they don't activate the watchdog, then at least you have this watchdog. But if it is always enabled, then you need to make sure every action is shorter than the timeout period. Longest actions are Flash erase, clocks stabilization. Don't rely only on this watchdog, also use second shorter watchdog in the application.
Note: the HW shall be designed in a way that the critical function is in safe state (e.g. disabled) when MCU is reset.
b) Implement endless boot loop prevention. Bootloader shall check resets reasons. If it was a watchdog reset, then something is wrong with the application. Use no-init RAM area to count how many times this happens. Usually after 3rd of 5th time the bootloader should not launch application again. Btw. you could use no-init RAM area for "flags" also.