Code Isolation for Functional Safety

[arthiJan]

HI,

  I am considering the use of STM32F0 device for my project. How do I isolate the safety related code(for functional safety)  from the general code, so that a f/w update on the general code doesn't affect the safety related code? Are there any hardware provisions on the STM32 devices to help me isolate these sections? Or are there any software means to isolate the two?

[Tesla DeLorean]

Look in the reference and data manuals and check the granularity of the flash write protection afforded.

Review the ARM Cortex-M0 manuals to understand it's capabilities and protections.

[Chris1]

Consider using a device that has an MPU (Memory Protection Unit) such as one of the STM32L4 or perhaps L5 families. The MPU allows you to restrict access to various regions of memory.

[Pavel A.]

Take ​two F0s. One for general code, another for safety stuff 🙂

-- pa

[AvaTar]

I agree. That's the way we did it usually (on Infineon and Cypress M3/M4 MCUs, though).

[arthiJan]

​Thanks. I am going to have to go that route, if I don't find a decent solution. I am trying to stick to one microcontroller, because of cost and real estate.

[arthiJan]

​Thanks. I am having trouble figuring out how to implement this. Would this mean I have to compile 2 separate .hex files , one for safety related code and other for general purpose code, load the safety code on restricted memory and other code in general memory?

[AvaTar]

No.

We add a suffix like "SAFE_CODE" to functions that are supposedly safe.

This suffix translates via preprocessor into a linking directive, which depends on your toolchain. Often something like "#[pragma section .....".]​ 

Place the safe code in a separate section this way (observing MPU alignment requirement).

[Chris1 · Accepted solution]

The concept is that the MPU is configured to allow your safety-related code to access the RAM and peripherals that it needs and other code is not permitted to access those resources.  

This makes a strong argument that the non-safety code is independent from (and cannot affect) the safety-related code.

Access to flash memory could also be controlled, but if your application treats flash as read-only memory, that would probably not be very beneficial.  

Ideally, an RTOS manages the MPU, changing the accessible regions when switching tasks (FreeRTOS and SafeRTOS have that ability, among others).

[arthiJan]

​Thank you very much for the tip. So, when its time to upgrade the fw, do I compile new code as one .hex and then only overwrite the general code sections of .hex?