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.

TMS320F28388D: CPU1 HWBIST success but CPU2 HWBIST Fail

Part Number: TMS320F28388D


Tool/software:

Hi,

When I integrating the HWBIST in our system, we use the Micro-Run.

When I am doing the CPU2 HWBIST, it will get the 0x19 retrun value of the STL_HWBIST_runMicro(), which means the HWBIST detected a logic error. I changed another chip, it face the same problem.

But when I did the HWBIST on CPU1, it can successfully finish the HWBIST 99% coverage with no error.

So I have some questions below:

1. Is there any difference of the HWBIST initial between the CPU1 or CPU2?

2. What can I do if this logic error happened?

The library version:
TI Release: C2000 Diagnostic Library v5_02_00_00

  • For supplement, the CPU2 HWBIST failed in the first time micro run.

  • Nai,

    For CPU2 HWBIST, have you attempted to claim and verify the semaphore for CPU2?  

    STL_HWBIST_releaseSemaphore();
    STL_HWBIST_claimSemaphore(STL_HWBIST_CPU02);
    This function should also return a boolean 1, if it was successful.  This should be verified before running HWBIST.
    Best,
    Matthew 
     
  • Matthew,
    Yes, it always checked if the semaphore is claimed successfully before I start the micro run.
    And for testing, I only run the CPU2 HWBIST, no CPU1 HWBIST.

    If you need more information, please tell me.

    Best Regards,
    Norman

  • Nai,

    Thanks for this, would you be able to export your project and share that with us so we can try it out here as well?  We are trying to replicate, but this will help to compare our code with yours, esp if we can't replicate.

    If you'd like to keep it off forum(very understandable) you can either share it with Matt C, or I can set up a private chat to share off forum.

    Best,

    Matthew

  • Hi Matthew,

    I have found the root cause of this issue:
    Good news! We traced the issue to a sequencing detail on CPU2: the HWBIST semaphore must be claimed and verified (boolean return = 1) before issuing any HWBIST initialization on CPU2. Earlier, our understanding of “running HWBIST” of your side didn’t explicitly include the initialization phase, which led us to verify the semaphore later in the flow.  

    Really thanks again for the help, it led us to the fix.

    Best Regards,
    Norman