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.

RM46L852: RM46L852

Part Number: RM46L852
Other Parts Discussed in Thread: HALCOGEN

Hello,

I am trying to use dual clock comparator in self test but I cannot find it in HALCOGEN. Please advise.

ALso regarding the CPU selftest(STC) any example code for saving the all context before starting the test?

  • Hello Vijayendra,

    I am not certain what your question is regarding the DCC. Are you referring to the DCC diagnostic during application execution or are you referring to the test for diagnostic? If the former, there is a DCC tab to setup the counter 1, counter 2 and expected counts, etc. There is also an appnote on how to measure/monitor the PLL using OSCIN as the source for counter0.

    In regard to STC and context save, we do not have any sample code for this. Are you planning to run STC on a periodic basis? This is the only case where context will need to be saved and STC ran at a time other than startup. For a complete list of registers that would need to be backed up and restored, please see the Cortex-R4F TRM on the ARM information center site.

  • Hello Chuck,

    Sorry for not being clear enough in my previous post.

    1. STC - we are planning to run STC on periodic basis. Hence wanted to save context and an example code would have helped alot.
    2. DCC - Dual clock comparator module - we will be using to Check the CPU clock frequency periodically. Again an example and way to implement this will be helpful.

    basically we are planning to run self tests periodically.
  • Hello Vijayendra,

    For the DCC question, we have an application note that describes how to use the DCC for checking the PLL output (feeds directly to HCLK and GCLK). The application note is available at this link: www.ti.com/.../spna211

    In regard to an example for backing up CPU registers, please have a look at this post:
    e2e.ti.com/.../122665

    For additional information, please have a look at this post: e2e.ti.com/.../391775

    The second post includes a brief list posted by the post author of registers that should be considered for context save. I have also posted some discussion points on why periodic execution of LBIST may not be needed. However, one point that is not identified is that reliance on only the core compare module for identification of CPU faults while protecting the safety operation of the system, will result in a single point fault at the point of use where periodic execution of the STC LBIST will allow for early determination of a potential problem; in other words the LBIST serves the function of Latent Fault Detection when the system is active for very long periods of time as with industrial applications. For shorter durations, the argument made in the thread stands up without issue including latent fault detection at boot time.