Functional safety requirements for application software
Safety Manual for MPC5777M, Rev. 1.1
NXP Semiconductors 57
PBRIDGEn should be configured to prevent any write access to the entire MC_RGM address space for all
masters except the Safety Core.
Assumption: [SCG18.133]Safety software shall program the Peripheral Access Control in the
PBRIDGEn so no write access to the MC_RGM_PRST[n] (individual module reset programming model)
is allowed to access other cores. [end]
3.4.4 Register protection (REG_PROT)
Accidental writes to configuration registers can affect the execution of the MCU’s safety function and
disable the safety mechanism due to their change. Register protection offers a mechanism to protect
defined memory mapped address locations in a module against writes. The address locations that can be
protected are module specific.
Register protection includes these distinctive features:
• Register protection can restrict accesses for the module under protection to supervisor mode. This
access restriction is in addition to any access restrictions imposed by the protected module.
• A register cannot be written once Soft Lock Protection is set. Soft Lock Protection can be cleared
by software or system reset.
• A register cannot be written once Hard Lock Protection is set. Hard Lock Protection can only be
cleared by system reset.
Recommendation: It is recommended that only hardware related software (OS, drivers) run in supervisor
mode.
Assumption: [SM_FMEDA_114]Configuration registers are to be locked 90% of the time, either by Soft
Lock or Hard Lock Protection, to prevent unwanted modifications. [end]
NOTE
Implementation hint: Each peripheral register that can be protected
through register protection has a Set Soft Lock bit reserved in the Register
Protection address space. This bit should be asserted to enable the protection
of the related peripheral registers. Moreover, the Hard Lock Bit
(REG_PROT_GCR[HLB] = 1) should be set for best write protection.
Assumption: [SM_FMEDA_171] The REG_PROT configuration registers shall be read and compared
against the expected values at least once after being programmed. [end]
3.4.5 Performance (Core_1) and Peripheral (Core_2) Cores
Performance (Core_1) or Peripheral (Core_2) cores are considered Non-safety modules (NoSaMo). If they
execute any safety task, counter measures must be used in application software.
Some hardware resources are shared between Core_1, Core_2 and the Safety Core (Master Core and
Checker Core). It is required that interference between Core_1 and Core_2 with safety relevant modules
is avoided.
To Next Page
Loading...
