• State Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 354 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.

Original question:

TDA4VM-Q1: J721e RTOS SDK version 8.05.00 SDL PBIST Example Queries

TDA4VM-Q1: SDL v1.0 BIST Module Usage and MCU2_1 problem

Haomin Jiang
Intellectual 315 points
Part Number: TDA4VM-Q1


Hi, 

I am trying to setup BIST on our system based on J721e by using SDL v1.00 in PDK 0805.

With the provided BIST examples and tests, I found that there are some differences upon BIST implementation between the example and the test.

Within the test folder for pbist and lbist, these two are similar for the sequence board init--> osal init --> run bist tests for all the instances(15 for pbist and 6 for lbist)--> restore.

But in the bist example, three boot stages are defined and the bist tests for all the instances are distributed to these three boot stages. Hence these bist instances are executed following a certain order like mentioned in the SDL guide:

Phase #0:

  • PBIST Negative and positive tests for Main Pulsar 0

  • LBIST test for Main Pulsar 0

Phase #1:

  • PBIST Negative and positive tests for Main Pulsar 1, C7x, C66x, VPAC and DMPAC

  • LBIST test for Main Pulsar 1, C7x, VPAC, DMPAC

Phase #2:

  • PBIST Negative and positive tests for A72, HC, Encoder and Decoder

  • LBIST test for A72

Why is the bist example doing so? Are there any dependencies among the cores/IPs? Can I simply implement the PBIST/LBIST by running all the bist instances one by one just like in the pbist/lbist test sources shown?

In addition, I run pbist for all instances as part of  SBL on our system before all other cores can run. All the pbist tests are passed and returned but the system cannot be boot up normally afterwards. After debugging I can see there is bus error reported in the below when setting up MCU2_1(Main domain R5F core1) ATCM:

It seems the operation of setting 0xFF to MCU2_1 ATCM is rejected after the pbist(successfully for MCU2_0). If I skip the pbist for MCU2_0/MCU2_1 and run the other pbist instances, the system can be boot up normally. Any idea why is this happening? 

Thanks for your patience.

  • 0
    Intellectual 315 points

    I checked with the associate responsible for boot manager and see there would be these 3 boot stages mentioned in the guide, but under what circumstances the SDL BIST will consider these boot-up stages? 

  • 0 in reply to Haomin Jiang
    TI__Guru** 122311 points

    Hi,

    Regarding

    "But in the bist example, three boot stages are defined and the bist tests for all the instances are distributed to these three boot stages. Hence these bist instances are executed following a certain order like mentioned in the SDL guide:"

    BIST testing is intrusive, and as such H/W modules which are undergoing BIST testing cannot be used for other purposes.   The staged approach provided by the SDL examples, allows for prioritization of H/W modules that are desired to be available earlier in the boot flow than others.  The earlier in the boot flow the BIST test is run on module, the earlier that H/W module could be released from reset.

    The "examples" directory is what would be used in integration with the SDK SBL boot flow.

    Regards,

    kb

  • 0 in reply to KB
    Intellectual 315 points

    Hi KB,

    Thank you for your reply.

    From my understanding, BISTs need to be done before the HW actually runs any programs, hence it is alright to make sure the HW completes its BISTs just before it loads any programs, not necessarily follow the boot stages defined in the example, right?

    If possible, I can run all the BISTs (except for MCU R5F) at the very beginning.

    KB said:
    The "examples" directory is what would be used in integration with the SDK SBL boot flow.

    So I see, in the integration with SDK SBL boot flow, it should be like pre-boot BIST-> pre-boot HW running->boot stage1 BIST-> boot stage1 HW running-> boot stage2 BIST-> boot stage2 HW running ....

    But why don't we just execute BISTs all in a very early stage?

  • +1 in reply to Haomin Jiang
    TI__Guru** 122311 points

    Hi,

    The example code provided in the SDL, is just that, an example.  Customization is expected to meet a particular product's needs.  For example, in all likely hood not all BISTs will be required to be run, where an unused H/W module need not have BIST run against it.   Similarly, the order in which BIST tests are run may be changed depending on needs.

    There is nothing wrong with an approach of running all desired BIST, prior to running any programs.   

    The example code as it is setup provides a "framework" for:

    • pre-boot stage - BIST tests to be run prior to Main Domain resources being setup
    • boot_stages - Ability to run BIST tests, at different stages of boot.

    Some documentation on this at 5.8. BIST Safety Example — Software Diagnostics Library (SDL) - J721E User Guide.   They way the example code is currently setup the Main Domain MCU2_0 could be up and running after Phase #0, before the rest of the BIST tests are run, provided that the code running on MCU2_0 is not making use of any of the H/W modules undergoing BIST testing from MCU Domain MCU1_0.   

    Regards,

    kb