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.

CCS/RM41L232: SafeTI:Questions about the usage of SL_SelfTest_Flash

Part Number: RM41L232
Other Parts Discussed in Thread: HALCOGEN

Tool/software: Code Composer Studio

Hello,
I am integrate SafeTI library to a system.The system runs on a RM41L232 MCU. According to safety manual of RM41Lx I select a diagnostic feature called [FLA1:Flash Data ECC]. For example, using the following function from SafeTI library to test Flash ECC's one-bit error.


retVal=SL_SelfTest_Flash(FLASH_ECC_TEST_MODE_1BIT, TRUE, &failInfoFlash);


Then if the above function detected Flash's one-bit error,ESM event will be triggered? If so, how do I verify this action?
and also by HALCoGen I generated some driver code and PMU was set to enable event export and ESM was to
enable channel 6[flash ECC single -low level] interrupt.
According to my understangding, if  Flash's one-bit error occurs, in VIM RAM ESM's esmLowInterrupt will be triggered?Is that right?


Looking forward to your answer.
Thanks.

  • Hello Lilly,

    Sorry for the delayed response. The single bit faults in Flash ECC are only triggered if configured to do so. i.e., I believe you have to enable this in both the Flash module by setting a limit (i.e., flag every single bit fault or only after a threshold has passed), and in the ESM by configuring the interrupt and nERROR behavior associated with the error flag (since this is a Group 1 error).

    In many cases, customers do not choose to be notified of single bit errors because they are corrected on the fly during runtime. The end results are the application suffers no bad behavior as a result of the error. A few customers will choose to enable notification of single bit faults, however, since when a threshold is passed in a small amount of time, it may indicate a radiation event that could eventually lead to application/system failure or it could indicate some decreased reliability due to aging, etc. This is something that isn't required from a device perspective, but may be required/recommended dependent on the nature of your application.