Tool/software:
Hello,
I would like to clarify the expected registers periodic check regarding Periodic software readback of static configuration registers.
I understood that those tests are related to configuration registers checks regarding the partition System Control and CPU which are not supposed to be modified at software runtime. I wanted to be sure that those test are not overlaping each others.
Then, it is I suppose "straight forward" for SYS3 safety mechanism to find in the tms570 technical manual (SPNU499C) the system registers which have a physical address to be checked. (sample of the registers below)
Then comes the CPU6 requested safety mechanisms and here I wanted to have a confirmation that expected registers checks are at Arm CPUR4F level on "internal" registers.
My understanding is that here we are talking about CPU registers to be checked which cannot be covered by the SYS checks.
According to Cortex
-R4 and Cortex-R4F Revision: r1p3 Technical Reference Manual, Chapter 4 System Control Coprocessor, shows how to program and checks internal CPU settings.
Then there are different registers described with write and read functionalities as System Control Register :
I can see that those core CPU registers are configured at early MCU startup provided by functions (via assembly instructions). Those are setup from SafeTi Library or configured by Halogen tool generation.
My question :
Is the goal of CPU6 test is to periodically read a determined amount (depending of the safety level to achieve for the system) of those CPU registers (which should not change) ?
If yes, do we need to implement some function using assembly instructions to read out the value as described in Cortex -R4 and Cortex-R4F Revision: r1p3 Technical Reference Manual ? (because this is not accessible via mapped MCU system control registers as for SYS3 test)
Thank you for the clarification,
Regards,
Marc
