• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 30 subscribers
  • Views 950 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM48L952: Relation between Safety Manual RM48 and SafeTI Diagnostics library / HalCoGen

K De Coster
Intellectual 740 points
Part Number: RM48L952
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 :
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."
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?
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 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?
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).
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:

DMA9A/B : "Boot Time/Periodic Software test of DMA MPU functionaility including error tests"

or DMA18 : "Software Test of MPU Functionality".

Thanks,

Karel

  • 0
    TI__Guru**** 193286 points
    Hello KArel,

    1. Your understanding is correct.
    2. A single test (writing to ROM) is sufficient for PBIST selftest.
    3. The Auto-coverage diagnostic measures are based on the probability of a random failure causing the mechanism such as CRC or BIST to falsely pass a test. In other words, if there is a random fault during the execution of the hardware CRC test/algorithm, the probability of the fault occurring in such a way that a failing CRC check would now pass due to this random fault is very, very small. This is a built-in safety measure that is based on the algorithm robustness and is included anytime the given algorithm (CRC, LBIST, PBIST) is used based solely on the probability of a false pass. There is no fault detection of the auto-coverage mechanism. Auto-Coverage is simply used as a test for diagnostic.
    4. You are right. The golden CRC value (expected CRC value) is needed to check the calculated CRC value.
    5. HalCoGen and Diagnostc library don't have any function to readback the co-processor registers.
    6. FBSE(Flash Bank Sector Enable Register) provides one enable bit per sector to enable/disable the program/erase access. This mechanism can reduce probability of unintended programming of Flash memory. For example in bootloader, you can not program the firmware by call programming command before enabling the flash sectors.
    7. Please use the following PCR registers to enable/disable the clocks to the peripherals
    PSPWRDWNSET0/1/2/3 and PSPWRDWNCLR0/1/2/3
    The HALCoGen doesn't have this option.
    8. You can CCM selftest or RAM ECC selfttest to test the ESM error path reporting.
    9. DMA9A/DMA18: is to access an MPU protected memory area and generate an ESM error.
  • 0 in reply to QJ Wang
    Intellectual 740 points

    Hi QJ Wang,

    Thanks for getting back to me so fast.
    Some questions are not quite clear yet to me:

    1) Answered
    2) Answered
    3) Because the auto-coverage (of CRC/PBIST) is a property of the CRC/PBIST it is automatically done if the CRC/PBIST is performed, right?
    4) Answered
    5) Answered (Coprocessor registers can be found in ARM R4F TRM)
    6) Answered
    7) Answered, HalCoGen does generate code to set these registers, combined with Table 6-20. Device Memory Map from RM48 TRM p 79 to see which peripheral is 0-31.
    8) OK
    9) Which test is covered by calling SL_SelfTest_DMA(DMA_SOFTWARE_TEST)?
        DMA9A/9B, or DMA18 or both?

    Regards,

    Karel

  • 0 in reply to K De Coster
    TI__Guru**** 193286 points
    Hello Karel,

    3. you are correct.
    5. Yes, the Coprocessor registers can be found in ARM R4F TRM
    9. It an be used for both.