• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 536 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Memory Initialization and Diagnostics

Guy Tadi
Intellectual 660 points
Part Number: RM48L952
Other Parts Discussed in Thread: HALCOGEN

I am trying to run PBIST on startup, but as expected this test is destructive which means my stack is destroyed after running PBIST. I know I can recover by resetting the CPU, but how do I determine, after this CPU reset, that I have previously run PBIST so that I don't run it again and get into an endless PBIST-Reset-PBIST-Reset... cycle?

Also, for tests that require Memory Initialization, the PC is reset to 0x00000000 and so when I complete the test I'm not able to return to the call stack. How do I recover and continue execution after such tests?

  • 0
    TI__Guru**** 196736 points

    Hello Guy,

    STC generates a CPU reset after completion of each test. But the PBIST will not cause reset. Please use the startup code generated from HALCoGen.The startup code checks the reset source and will not do CPU selftest if the reset source is CPU reset.

    Memory initialization uses the system module's hardware for auto-initialization of memories and their associated protection schemes. It will initialize the entire CPU RAM and the corresponding ECC locations. But it will not clear the MCU registers (PC, CPSR, etc).

  • 0 in reply to QJ Wang
    Intellectual 660 points
    Thanks. I'm already using the startup code that checks for reset cause so I'm OK with STC. You confirmed my observation that PBIST doesn't cause a reset. So this means I must generate CPU reset at the end of PBIST and then rely on my startup reset handler to ensure PBIST doesn't execute again (like how it's done for STC). Is this a reasonable approach?
  • 0 in reply to Guy Tadi
    TI__Guru**** 196736 points
    PBIST doesn't generate reset, so stopping running doesn't solve the problem. Please check what is the root cause of the endless cycles: PBIST-Reset-PBIST-Reset... cycle?
  • 0 in reply to Guy Tadi
    Intellectual 660 points
    What's the difference between cpuSelfTest(STC_INTERVAL, STC_MAX_TIMEOUT, TRUE) and SL_SelfTest_STC(STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)? They both seem to be doing STC self test.

    Also, can you respond to my other question:
    ...my observation [is] that PBIST doesn't cause a reset. So this means I must generate CPU reset at the end of PBIST and then rely on my startup reset handler to ensure PBIST doesn't execute again (like how it's done for STC). Is this a reasonable approach?

    I'm still not sure how to recover from memory auto-initialization during diagnostics since it reset my PC = 0
    Thanks.
  • 0 in reply to QJ Wang
    Intellectual 660 points

    Let me clarify what I mean by PBIST-Reset cycle. There is no actual Reset occurring as a result of the PBIST. However, I'm finding that some of the PBIST tests require a call to memory auto-initialization. When this happens the PC is set to zero at the bottom of the stack so I am returned to the reset vector after popping the stack. This causes execution to start from the beginning and hence repeats the PBIST runs.  How do I handle this to get out of the cycle?

    Also, what's the difference between cpuSelfTest(STC_INTERVAL, STC_MAX_TIMEOUT, TRUE) and SL_SelfTest_STC(STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)? One or the other is called on startup based on the rest reason but they both seem to be doing STC self test.

  • 0 in reply to Guy Tadi
    Intellectual 660 points

    I'm till hoping for response to my two questions repeated here:

    1. I'm finding that some of the PBIST tests require a call to memory auto-initialization. When this happens the PC is set to zero at the bottom of the stack so I am returned to the reset vector after popping the stack. This causes execution to start from the beginning and hence repeats the PBIST runs.  How do I handle this to get out of the cycle?
    2. Also, what's the difference between cpuSelfTest(STC_INTERVAL, STC_MAX_TIMEOUT, TRUE) and SL_SelfTest_STC(STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)? One or the other is called on startup based on the reset reason but they both seem to be doing STC self test.

    and my new third question:

    When I run the cpuSelfTest with default interval of 24U and SelfTest_STC, my startup is delayed by about 40 seconds with multiple resets. Is this an expected behavior?

    Thanks.

  • 0 in reply to Guy Tadi
    TI__Guru**** 196736 points
    Hello Sir,

    1. No, the memory initialization is not required before doing the PBIST test. Not all algorithms are designed to run on all RAM groups. If an algorithm is selected to run on an incompatible memory, this will result in a failure. There is no watchdog functionality implemented in the PBIST controller. If a bad code is executed, the PBIST will run forever. If you use old rev device (revA or revB), please run the pbist workaround for the bug PBIST#4. This workaround is generated through the HALCoGen 4.07.01.: errata_PBIST_4();

    The contents of the selected memory will be completely lost. User code must take care of data backup if required.

    2. The STC is CPU self-test controller used to test the CPU core LBIST. The STC is Capable of running the complete test as well as running a few intervals at a time.

    cpuSelfTest(STC_INTERVAL, STC_MAX_TIMEOUT, TRUE) is used to do CPU self test.
    you can use SDL API for CPI self test: SL_SelfTest_STC(STC_RUN, ...).

    STC has the feature to do self check for STC itself. This STC self check is only done for STC interval 0 by insering stuck-at-fault inside CPU.
    SL_SelfTest_STC(STC_COMPARE_SELFCHECK, TRUE, &stcSelfTestConfig)

    The CPU self-test executes the selected number of test intervals and then causes a CPU reset (not system reset).