About diagnostic method of "INC1".

Hello Sazabi,

In general, yes. L2 and L3 interconnect should be tested if both are used as part of your safety function. If there are questions on how to inset the errors on the bus, please refer to the SafeTI Diagnostic Library which is available for free download at .

If you can't locate the specific test or have difficulty in understanding, please let me know and we can work through the details together.

Hello Chuck,

Thank you for the explanation.

Currently I downloaded the library (safety_library) introduced and I am looking at the contents.
(1) For the question "INC 1", I think that the function "SL_SelfTestL 2 L 3 Interconnect" is applicable, but is that recognition recognized correctly?
(2) Is this function performing fault insertion for INC1 (L2 / L3)?
(3) If this function is executed, is it possible to insert "fault insertion" for INC1 (L2 / L3)?
(4) When this function is executed, which register of esm is notified of the error?
(5) Can you provide "detailed instructions" on the "Safety Library" that introduced me, details of the implementation details?

Best Regards,

Sazabi

Hello Sazabi,

Have you had a look at the included documentation? I think it will answer all of the questions you have posted. The documentation is included in the directory C:\ti\Hercules\SafeTI Diagnostic Library\2.2.0\docs (although your version of the library may be newer)

Hello Chuck,

I'm sorry.
Due to the management of the server, this document was kept separately, so I overlooked it.
After reviewing the contents of the document in the path you taught, I will implement it here by referring to the library code.

Best Regards,

Sazabi

Hello Sazabi,

I am glad that you were able to find the documentation. Please let us know if there are any further issues or clarification that is needed when you reference the included manuals.

Hello Chuck,

Thank you for the explanation.

Currently I downloaded the library (safety_library) introduced and I am looking at the contents.

Please tell me about the function "_SL_Barrier_Data_Access ();" executing the memory barrier instruction (DMB, DSB).

(1) Do you recognize that the test of L2L3_Interconnect is being executed with "SL_SelfTestL2L3Interconnect (SL_SelfTestType testType)" executing this arm instruction?
(2) The function "_SL_Barrier_Data_Access ();" which executes the memory barrier instruction (DMB, DSB) is called from this function. By executing this function "_SL_Barrier_Data_Access ();" will it be said that the interconnection of "all peripherals (L2 / L3)" defined by "INC1" is normal?

Best Regards,

Sazabi

Hello Sazabi,

I've forwarded your question to one of our SW team experts. They will be able to give more detailed responses on the the software implementation. Unfortunately, the expert is currently of office. They will respond when they return to the office. Please let me know if you don't hear back from them within the next 4-5 days or if you would need an answer sooner.

Hello Chuck,

Thank you for your response.

>>Please let me know if you don't hear back from them within the next 4-5 days or if you would need an answer sooner.

Regarding this question, how is progress after that?

Best Regards,

Sazabi

Hello Sazabi,

The specific SW expert is still out of the office. I have also reached out to other SW team members to see if one of them can have a look at your question. Sorry for the delays.

Hello Sazabi,

Please see the section 6.4.1 of the software safety manual for the SafeTI Hercules Diagnostic Library (Criteria for Usage of SafeTI Hercules Diagnostic Library API). The Safety manual recommends that the diagnostic test be run at highest priority in the system, without interruption, to ensure that the functions are correctly tested and that the device is in a correct state.

To your question, the DMB/DSB instructions ensure that any memory operations in the CPU are completed prior to the trigger of the actual test. The intention is that the required settings for the test to be checked are correctly set. It should not have any effect on the execution of the test itself.

Thanks and regards,
Girish

Hello Girish,
Hello Chuck,

Thank you for the detailed explanation.

I understand that "_SL_Barrier_Data_Access();" is "preparation" to successfully execute "selftest" of the L2/L3 interconnection.

Then the function executing the "selftest" of the L2/L3 interconnection is:

boolean SL_SelfTestL2L3Interconnect (SL_SelfTestType testType);

If the return value of this function is "TRUE", will you be able to diagnose that all interconnections of L2/L3(below) are working properly?
· L2: VBUSM_SCR {1 module}
· L3: SCR1(AHB_BMM), SCR2(VBUSP_SCR), SCR3(VBUSP_SCR), SCR4(VBUSP_SCR), PCR {5 modules}

Best Regards,

Sazabi

Hello Girish,
Hello Chuck,

# I posted again because I failed to post.

Thank you for the detailed explanation.

I understand that "_SL_Barrier_Data_Access();" is "preparation" to successfully execute "selftest" of the L2/L3 interconnection.

Then the function executing the "selftest" of the L2/L3 interconnection is:
Boolean SL_SelfTestL2L3Interconnect (SL_SelfTestType testType);

If the return value of this function is "TRUE", will you be able to diagnose that all interconnections of L2/L3(below) are working properly?

· L2: VBUSM_SCR {1 module}
· L3: SCR1(AHB_BMM), SCR2(VBUSP_SCR), SCR3(VBUSP_SCR), SCR4(VBUSP_SCR), PCR {5 modules}

Best Regards,

Sazabi

Hello Sazabi,

Generally speaking, the answer to your general question is yes. These tests will demonstrate that the interconnect is operating per design. For full coverage from a safety perspective, ,there may be some choice to also implement some of the other safety mechanisms or to pick up some coverage for latent faults by choosing to run some of the tests for diagnostics as well (the external sequence aware watchdog should be considered at a minimum). This, of course is dependent on your system implementation needs and resource availability.

Hello Chuck,

Thank you for the detailed explanation.

I was able to confirm the operation "dabort" by fault insertion using "SL_SelfTestL2L3 Interconnect" function implemented in "SafeTI Hercules Diagnostic Library".

(1) The safety function of "INC1" is the "mechanism of hardware", and the safety function of "INC1" need not be implemented as periodic self-diagnosis by software. Is this understanding correct?

Best Regards,

Sazabi

Hello Sazabi,

Implementation of this test and other tests of function on a periodic basis is something that you as the system integrator need to decide.

In our case study for certification, we assumed an automotive operational profile and in that context we did not believe that it was necessary to do this and other tests of function on a periodic basis. However, in this automotive mission profile the ON time is relatively short. In cases where an industrial profile is used/considered, the ON time may be significantly long that there are concerns with accumulation of faults that could become dangerous faults should they manifest themselves when a particular element is used.

My apologies for avoiding the question to a certain degree, but; since we cannot ever have the detailed view of your application that you have, we can't assume or advise how to implement the safety diagnostics beyond some very high level advice relative to the safety standards and device specific impact. This is why it is considered a system integrator decision.

Hello Chuck,

Thank you for the detailed explanation.

Please reconfirm the same question after changing the condition to do Selftest.

Even when SelfTest of this "INC 1 mechanism" is changed to the specification "executed only once at the time of activation (for example, implemented with PowerOn sequence)" instead of "periodically", the safety function of "INC 1" It is not necessary to implement it as a diagnosis. Is this interpretation correct as well?

Best Regards,

Sazabi

Hello Chuck,

Thank you for the detailed explanation.

I confirmed variously, but as a conclusion, do you agree with the recognition of (1) (2) below?

(1) The safety function of INC1 is "mechanism" of hardware.
→ Therefore, there is no need to implement self-diagnosis function as software.

(2) Failure insertion of INC1 can be inserted using "SafeTI Diagnostic Library".
→ It was possible to check the operation using CCS and test board here.

Best Regards,

Sazabi

Hello Sazabi,

To repeat my assertions in my prior posts, it is up to you as the system integrator to make final judgment about the needed safety diagnostic measures in your application including each of the diagnostics described in the Safety Manual. TI provides the scenario considered during our device level certification as a system out of context (SooC) in which we assume all mechanisms to be used as prescribed in the safety manual. However, each usecase is different and may allow for optimization of mechanisms used.

With that stated and to address your specific questions:

Sazabi said:

(1) The safety function of INC1 is "mechanism" of hardware.
→ Therefore, there is no need to implement self-diagnosis function as software.

This isn't a true statement. Being a hardware safety mechanism does not mean that you can skip a software test of function to ensure the absence of latent faults in both the detection mechanism and the fault notification path if and when it is possible. Not all hardware implemented features will have the ability to be tested, but I think this case is possible for INC1.

Sazabi said:

(2) Failure insertion of INC1 can be inserted using "SafeTI Diagnostic Library".
→ It was possible to check the operation using CCS and test board here.

Yes, the SafeTI library has a software based test of function including errors.

You also posted this in response to my initial response regarding periodic execution of the INC1 diagnostic:

"Even when SelfTest of this "INC 1 mechanism" is changed to the specification "executed only once at the time of activation (for example, implemented with PowerOn sequence)" instead of "periodically", the safety function of "INC 1" It is not necessary to implement it as a diagnosis. Is this interpretation correct as well?"

Again, this is a system integrator decision but as I mention for point 1 above, you need to consider the point of latent faults even for operational profiles with very short profiles and, certainly, you need to consider accumulation of faults for longer ON time applications as seen in the industrial application areas.

Hello Chuck,

Thank you for the detailed explanation.

I acknowledged it. The self-diagnosis function of INC 1 is scheduled to be implemented with the following policy, paying attention to Chuck's pointed out contents.
· Self-diagnosis function of INC 1 is a hardware mechanism, but as software, self-diagnosis function should be implemented.
· The self-diagnosis function of INC 1 does not make implementation decision by individual's discretion. Be sure to make a judgment through review with the team and experts (eg system integrator).

Then, next is a question about "Implementation for periodically self-diagnosing INC1". In other words, it is the safety function of "INC 1", which means "Which module is targeted" on a regular basis and what "to watch" for the target module should be monitored.
Just like other safety functions, it is easy to monitor the "ESM register" to determine the presence or absence of an error, but I believe that "INC 1" is not so. So there is a question;

--------
· About L2 (SCR);

(1-1) As a safety function of "INC1", is a "function module" to be monitored steadily, all modules corresponding to (a)-(b) below?
(a) "EMIF" used in "SafeTI Diagnostic Library".
(b) Like the EMIF, a functional module that is connected to SCR and "enable" with "HALCoGen".

(1-2) As a safety function of "INC1", what is a method for constantly monitoring that a module (eg EMIF) connected to L2 (SCR) is functioning properly?
(For example, in order to constantly check EMIF registers, which registers should be monitored so that "INC1" can be satisfied?

--------
· About L3 (PCR); (Question contents same as L2)

(2-1) As a safety function of "INC1", is a "function module" to be monitored steadily, all modules corresponding to (a)-(b) below?
(a) "DCAN" used in "SafeTI Diagnostic Library".
(b) Like DCAN, a functional module connected to PCR and "enable" with "HALCoGen".

(2-2) As a safety function of "INC1", what is a method of constantly monitoring that a module (eg DCAN) connected to L 3 (PCR) is working properly?
(For example, in order to constantly check DCAN registers, which registers should be monitored so that "INC1" can be satisfied?


Best Regards,

Sazabi

Hello Sazabi,

Let me address item by item.

Sazabi said:

· Self-diagnosis function of INC 1 is a hardware mechanism, but as software, self-diagnosis function should be implemented.
· The self-diagnosis function of INC 1 does not make implementation decision by individual's discretion. Be sure to make a judgment through review with the team and experts (eg system integrator).

In this point, you are correct in your understanding.

Sazabi said:

Then, next is a question about "Implementation for periodically self-diagnosing INC1". In other words, it is the safety function of "INC 1", which means "Which module is targeted" on a regular basis and what "to watch" for the target module should be monitored.
Just like other safety functions, it is easy to monitor the "ESM register" to determine the presence or absence of an error, but I believe that "INC 1" is not so. So there is a question;

I don't understand the comment "it is the safety function of "INC 1", which means "Which module is targeted" on a regular basis and what "to watch" for the target module should be monitored."

I believe the the result of an identified error for INC1 will be a device exception not an ESM error. I believe the line of questions have been targeted at the tests for diagnostic which are either boot time execution of SW test of function including errors and periodic boot time execution of SW test of function including errors. The execution of these tests for diagnostic is the decision point for the system integrator in order to determine if there are any latent faults present in the INC1 HW detection logic.

In the end, this safety diagnostic is very broad and there are many different possibilities for errors from any of the peripheral's. The provided test for diagnostic in the safeTI library uses two modules that are on different peripheral central resources to trigger the fault associated with this diagnostic in order to check the error notification logic as well as the error path testing. Specifically, unimplemented addresses within the modules defined address space is accessed. This results in an access error from the trapping feature in the hardware.

Sazabi said:

(1-1) As a safety function of "INC1", is a "function module" to be monitored steadily, all modules corresponding to (a)-(b) below?
(a) "EMIF" used in "SafeTI Diagnostic Library".
(b) Like the EMIF, a functional module that is connected to SCR and "enable" with "HALCoGen".

(1-2) As a safety function of "INC1", what is a method for constantly monitoring that a module (eg EMIF) connected to L2 (SCR) is functioning properly?
(For example, in order to constantly check EMIF registers, which registers should be monitored so that "INC1" can be satisfied?

--------
· About L3 (PCR); (Question contents same as L2)

(2-1) As a safety function of "INC1", is a "function module" to be monitored steadily, all modules corresponding to (a)-(b) below?
(a) "DCAN" used in "SafeTI Diagnostic Library".
(b) Like DCAN, a functional module connected to PCR and "enable" with "HALCoGen".

(2-2) As a safety function of "INC1", what is a method of constantly monitoring that a module (eg DCAN) connected to L 3 (PCR) is working properly?
(For example, in order to constantly check DCAN registers, which registers should be monitored so that "INC1" can be satisfied?

As I mentioned previously, the error trapping on the bus can detect errors with bus transactions with any of the peripherals on the bus. The result of an error will be a device exception in the form of a prefetch or data abort. Your code would need to have a prefetch or data abort handler to process these exceptions. Generally, when an exception of this nature happens, it takes some fairly detailed debug to check the various registers such as the PC and the LR registers to determine which code was being executed previously. For this reason, what ususally happens when an abort happens is some basic diagnostic such as test of the logic to make sure the logic wasn't falsely identifying an error due to a latent fault and perhaps triggering of a software reset to "start fresh."