Other Parts Discussed in Thread: HALCOGEN
Hello,
For our application we are using a Hercules RM48L52 MCU, we have a couple of questions regarding the Safety Manual [spnu577d], mainly about the relation with the SafeTI Diagnostics library (V2.4.0) and HalCoGen. I have found the "Safety manual to API mapping" page in the User guide of the SafeTI Diagnostics Library. However sometimes it is not clear to me which argument has to be handed to the functions to cover a certain test.
1) The Safety manual uses two flavors of usage : Diagnostic and test-on-diagnostic.
We have to :
We have to :
a . pick the Diagnostics which diagnose the safety critical components of our system
b . ensure they are enabled (i.e. enable ECC on RAM)
c . define the error handling for reported errors by this diagnostic (i.e. ISR)
d . implement/use a (single?) "test-on-diagnostic" that covers this diagnostic
That´s how I interpreted this table. Is this correct?
2) RAM14/VIM12/DMA16 are all Software Test of PBIST. The SafeTI library refers to the "SL_SelfTest_PBIST" function with the note
" Use failing tests on PBIST - see device safety manual for details."
The Safety Manual says:
"It is possible to configure the PBIST logic by selecting an algorithm that should fail, and seeing if the
PBIST Logic reports an error under this condition. For example, a read-write test could be performed on a
read-only memory to ensure that a failure is reported. An alternative scheme is to run a test for memory
with more bits than are actually present on the device memory."
The Safety Manual says:
"It is possible to configure the PBIST logic by selecting an algorithm that should fail, and seeing if the
PBIST Logic reports an error under this condition. For example, a read-write test could be performed on a
read-only memory to ensure that a failure is reported. An alternative scheme is to run a test for memory
with more bits than are actually present on the device memory."
HalCoGen generates the "pbistSelfCheck()" function to perform this test.
Is a single test (writing to ROM) sufficient to guarantee the correct functioning of the PBIST or do I have to run a failing PBIST for every memory?
3) RAM15/RAM19/CPU9/VIM11/VIM13/FLA15/.. "Auto coverage"
"Auto coverage" is claimed to be a test-on-diagnostics multiple times. The explanation says that because only 1 out of 2^n values is correct, it is unlikely a correct value is generated if there is a fault in the CRC calculation/PBIST. This seems to be confirmed by the "N/A; implicit in CRC/PBIST operation" in the "Text Execution Time" column. If we perform the SRAM PBIST (RAM7A) can we then automatically claim RAM15 the PBIST auto-coverage is done?
"Auto coverage" is claimed to be a test-on-diagnostics multiple times. The explanation says that because only 1 out of 2^n values is correct, it is unlikely a correct value is generated if there is a fault in the CRC calculation/PBIST. This seems to be confirmed by the "N/A; implicit in CRC/PBIST operation" in the "Text Execution Time" column. If we perform the SRAM PBIST (RAM7A) can we then automatically claim RAM15 the PBIST auto-coverage is done?
4) RAM18 "Software test of hardware CRC"
If the CRC peripheral is only used to calculate a CRC, not to evaluate it against the "golden value" (this is done by the CPU), then intentionally introducing errors to create a mismatch between the calculated CRC and "golden value" seems meaningless. Agree?
5) CPU6 / CPU7 : "periodic software readback of static configuration registers / Software readback of CPU registers"
It took me a while to figure out which registers are meant here, from the Cortex R4F TRM it seems like the CPU Coprocessors are : Floating-point unit, TCRAM, ... Setting these control registers is done in assembly with the mrc and mcr instructions (in sys_core.asm generated by HalCoGen). This is how ECC is enabled for example.
It took me a while to figure out which registers are meant here, from the Cortex R4F TRM it seems like the CPU Coprocessors are : Floating-point unit, TCRAM, ... Setting these control registers is done in assembly with the mrc and mcr instructions (in sys_core.asm generated by HalCoGen). This is how ECC is enabled for example.
It seems to me that implementing a readback is only achievable through assembly, I find no supporting functions for this in the SafeTI library or HalCoGen. Is it correct that there is no support for this?
Where can I find an oversight of the coprocessor configuration registers?
Where can I find an oversight of the coprocessor configuration registers?
6) FLA7 : "Flash Sector Protection" / FLA13 "Software test of flash sector protection unit"
The purpose of the Flash Sector Protection is unclear to me. Is it to protect against unintentional erasing of a flash bank by the CPU (some kind of bootloader) or from external sources (JTAG?)?
Is it necessary to test this if the application does not use flash writing API's?
7) INC2 "PCR Access Management"
How can I disable the unused peripherals? There is no PCR tab in HalCoGen and I do not find API functions to do this. Is this done automatically by HalCoGen when you unmark the "enable driver" checkbox?
8) ESM2B Error part reporting
This can be tested by executing the CCM selftest as this reports an ESM error, however this only tests 1 of the error paths.
Not all ESM error paths can be tested (as some will directly lead to an abort).
This can be tested by executing the CCM selftest as this reports an ESM error, however this only tests 1 of the error paths.
Not all ESM error paths can be tested (as some will directly lead to an abort).
Is testing one error path sufficient to claim this diagnostic is tested?
9) DMA9A/DMA9B/DMA18
The SafeTI diagnostics library documentation says that SL_SelfTest_DMA is the function to use to test these (and DM12).
On R4 devices the function can do two tests DMA_SOFTWARE_TEST and DMA_SRAM_PARITY_TEST. It is obvious that DMA_SRAM_PARITY_TEST matches with DMA12.
It is not clear with which test DMA_SOFTWARE_TEST matches:
On R4 devices the function can do two tests DMA_SOFTWARE_TEST and DMA_SRAM_PARITY_TEST. It is obvious that DMA_SRAM_PARITY_TEST matches with DMA12.
It is not clear with which test DMA_SOFTWARE_TEST matches:
DMA9A/B : "Boot Time/Periodic Software test of DMA MPU functionaility including error tests"
or DMA18 : "Software Test of MPU Functionality".
Thanks,
Karel
