tms570ls3137 Diagnostic Library API problem

Hello,

I have forwarded your question to one of our Halcogen and Diagnostic Library experts. They should get back with you shortly.

Hi

In order to avoid confusion by maintaining two separate start_up.c files (one generated by HALCoGen, the other by safety library) we have plugged in all our API calls into the HALCoGen generated start_up.c
This has been inserted as sections of code in the HALCoGen generated file (blocking the default HALCoGen calls with #if 0 and #endif directives)

The start_up.c mainly calls initialization APIs to set up clocks, peripherals, memories, flash settings etc...
Also, as a general recommendation, we call PBIST on some memories (as if done during application execution may corrupt memories)
Some other self tests on STC and other modules are also called during start_up

The application code is placed in the main function, this way keeping start_up isolated from any application specific tasks (API calls)
It is recommended to call the fault inject APIs in the main function (as this is what corresponds to the application code) which would then subsequently be handled by the application
As such there is no requisite for any special config for using them

I'm not quite sure why you would be getting any grp3 error. Please try re-setting the error pin to high again (using the error key register - please refer TRM) to remove the error and try running again

I used the default project supplied in the installer and just tested on my side and the code runs straight till main without any issues.
Have you modified the start_up.c? More details as to what is the source of the grp3 error (check from register) would be helpful

Regards,
Sharath

Hi Sharath,

I tried again, the API almost can be used in the main function. But I find the other question. I can inject one bit fault to SRAM. And I can see the report in ESM. When I want to inject two bit fault to SRAM. It become useless again. I can not find any report in ESM. And I find two bit error may lead to aborting CPU. Then aborting CPU occurred, how can I get report from ESM or how to know the abort occurred and how to restore the CPU?

Regards,
Cyrus

Hi Sharath,

I cannot read the "sl_SRAM_self_test" function of API clearly. How does it inject 1bit fault to the SRAM? Why do I use the same way to inject the other fault that cannot run successfully? 

And I use 2.1.0 diagnostic library.

And I do not know why just SRAM_ECC_ERROR_FORCING_1BIT is 0xA0? And why is 0xA0?

 

I used like this in the main function? Only 1BIT fault can run successfully.

Hi,

I infer that TCRAM_SYN_2BIT_DATA_ECC may something wrong so that in the SRAM self test function *ECCB1^=TCRAM_SYN_2BIT_DATA_ECC get an error value. But I do not know what value should get to this define?

Hi,
Would you mind forward my question to one of our Halcogen and Diagnostic Library experts. Looking forward to your reply. Thanks a lot.

Regards,
Cyrus

Hi

The 0xA0 used in defining the enum acts as a base index value for the enum. Thus SRAM_ECC_FORCING_1BIT takes up the value 0xA0, the subsequent elements are assigned continuous values incremented by 1 each time. The use of this is to just reference a particular test type in execution currently (passed as a parameter to the SelfTest APIs)

The 2 bit ECC error injected leads to a data abort upon accessing that location. It is then handled by the exception handler which in turn invokes the application callback provided with the demo application (ESM_ApplicationCallback)

I'm able to run the code successfully, for instance with call to SL_SelfTest_SRAM(SRAM_ECC_2BIT_FAULT_INJECT);

I presume that you are using the default start_up.c which comes with the installation package of the SafeTI Diagnostic Library.

Earlier you had said that you removed all other API calls in main, does that include the below API as well?
SL_ESM_Init(ESM_ApplicationCallback);

This API needs to be invoked before calling any of the other selftest APIs because this API sets up the exception handlers.