• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Subscribers 31 subscribers
  • Views 2221 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.

How to make sure the PBIST was executed on the right way on TMS570

J Yin
Intellectual 295 points
Other Parts Discussed in Thread: TMS570LS20216, TMS570LS20206, TMS570LS10206, TMS570LS10106

I wrote a piece of code for PBIST function and debug it on TI Dev board.

After I start the testing by set DLR = 0x14, (following the example on the reference manual exactly ), it seems that the MSTDONE bit was set to 1 immediately (no more than 1 ms).  

Because I run all algorithm on all RAM groups, it should take around 30 ms (HCLK=80M, VCLK=80M, ROMCLK=80M) based on the estimation on the manual but it's not. So I doubt if the testing code has been run or not, even the RINFOL register shows that the correct RAM Groups were selected for the last applied algorithm.

Is there any way to find out  if the PBIST is working or monitor the algorithms were applied one by one?

thanks

  • 0
    TI__Genius 14205 points

    Hi J Yin,

    Could you please send us the code snippet of your PBIST register configuration?. Also MSTDONE gets set the moment PBIST is done it can be pass or fail, you have to look at FSRF registers in PBIST to know PASS or FAIL status.

    Best Regards
    Prathap

     

     

  • 0 in reply to Prathap
    Intellectual 295 points

    Hi,  

    the register configuration as following

    SYSTEM_1->MSINENA = 0x01;

    SYSTEM_1->MSTGCR = 0x0A;

    /* waiting 32 cycles */

    pbistREG->PACT = 0x03;

    pbistREG->ALGO = 0xFFFF;

    pbistREG->PBISTOVERRRIDE = 0x01;

    pbistREG->ROM =0x03;

    /* run pbist */

    pbistREG->DLR =0x14;

    I found the problem is that after running pbist, the system was always been reset. that's why I can't run a timer to measure the execution time.

     

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Hi,

    PBIST completion will not trigger reset, could you please check if there is any ESM error or Aborts occured during your test.  Since you are running PBIST on ALL RAM's I assume you have taken care of handling device RAM backup and initialization and your code is running out of Flash.

    Also immediately after Reset ( As a first check) please read System Exception Status register ( offset 0xE4 in system module) just to check what caused reset.

    Best Regards
    Prathap

  • 0 in reply to Prathap
    Intellectual 295 points

    Hi,

    I run the pbist before device initialisation, so I think I don't need backup the device RAM. But I found if I run the testing for ESRAM (Ram Group 6), it cause a reset (the PC just go to address 0x0).

    I didn't found much information about ESRAM on the manual, but it seems that ESRAM has the same address as system RAM (start at 0x08000000). So, the PBIST override all system RAM that causes a reset.

    I am not sure if PBIST should work in this way, I mean you must reset system after PBIST.

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Hi

    For  TMS570LS series (TMS570LS20216, TMS570LS20206, TMS570LS10216,  TMS570LS10206, TMS570LS10116, TMS570LS10106) of devices maximum algorithm that can be run on bench / Silicon is only 16. See Table 6.2 in the Technical reference manual. http://www.ti.com/litv/pdf/spnu489a 

    So the ALGO regiser can have value = 0x000000FC ( excluding the ROM check).  Also refer the PBIST configuration example in Technical reference manual to get more info on the flow.

    Best Regards
    Prathap

     

  • 0 in reply to Prathap
    Intellectual 295 points

    Sorry, I didn't got your point. Did you mean my configuration of register is wrong?

    I know the TMS570LS only support 16 algorithms, so the ALGO should be set to 0x0000FFFF, is this wrong?

    Please see the reference manual page 225, if I made a misunderstanding, please let me know.

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Hi

    I am so sorry I meant to type ALGO = 0xFFFC ( Excluding ROM).
    I tried a similar setup at  my bench and it worked, see the attached code snippet that I used. Pls check if there is some registers or flow that is done differently.

    3817.PBIST_Test.c

    Best Regards
    Prathap

  • 0 in reply to Prathap
    Intellectual 295 points

    Hi, 

    In your code:

    e_PBIST_ST.ALGO_UN.ALGO_UL=0xFFFF;/* It seems your didn't set OVER = 1, and using default value of RINFOL (0xFFFFFFFF). In this case, you will get a failure. FSRFx= 1,  don't you?*/

    e_PBIST_ST.RINFOL_UN.RINFOL_UL=0x7FFF;  /* In Table 6-1, there are only 14 Ram Groups, so it should be 0x3FFF */

    if #if 0 goes to #if 1,

    /*Step 7: selcting Run selft test without RAM overide*/

    e_PBIST_ST.PBISTOVERRRIDE_UN.PBISTOVERRRIDE_ST.OVER=0x01; /* If you want do test without RAM override, OVER should be set to 0x0 not 0x01 */

     

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Hi

    OVER is set by default (OVER = 1) , which gives us the flexibility of not providing any info on the RINFOL and RINFOU since it will be overridden.
    Just selecting the necessary ALGO and you are good to go.

    Please ignore the codes in the #if 0, I was experimenting some stuffs..

    Have you tried similar code flow and settings at your bench?

    Best Regards
    Prathap

     

  • 0 in reply to Prathap
    Intellectual 295 points

    I have done the same configuration exactly, but after self testing, the function return to address 0x0.

    I test Ram Group one by one and found if I do testing on RG6, it will go to address 0x0.

    I found the same problem on Demo program that was provided with the development kit CD. 

    Can you run that Demo program on your platform to see what happens?

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Following are the steps I tried at my bench

    1) Created Pjt that with Linker cmd configured with Flash at 0 and RAM at 0x08000000
    2) I used the main pbist.c file which i atached in my previous post.
    3) Flashed the execuable(.out) to the micro using nowFlash
    4) The code had a branch to itself (   B $) at the beginning so that I get stuck at that line incase of reset.
    5) At fis skipped the Branch to itself routine and executed the code.
    6) The code successfully gets executeed and reaches the while(1) routine at the end of main file, no reset occured and main RAM was also part of he PBIST test.

    Best Regards
    Prathap

     

     

     

     

     

  • 0 in reply to Prathap
    TI__Mastermind 23000 points

    When executing the PBIST, please ensure that you do not test the memory from which you are executing.  This is a bit silly, but it has happened to me during my testing more than once, especially when I have remapped SRAM memory into the normal flash address space.

     

    Best Regards,

    Karl 

  • 0 in reply to Prathap
    Intellectual 295 points

    Hi, Prathap

    I only got your .c file, it hard to run your code on my board.

    I attached the Demo project that comes from TI installation CD, I run this program and got the same reset problems.  That is: I set break point at pbistStartSelfTest(). When touch it, I do Go Step in debugger, it will jump to address 0x0.

    Could you please run it on your bench?

    thanks

    3302.Demo_Software_Ver1_1.zip

  • 0 in reply to KGreb
    Intellectual 295 points

    Hi, Karl

    Could you please explain more about your fault?

    In my view, because the SRAM has the same address s[ace as system main RAM, the content of the RAM must be override during PBIST. If I monitor the stack when run PBIST, I can see the stack was set to all 0 during the test, which means the return address of the application was reset and the PC was load to 0x0. In this case, the program must be reset.

    Is this same as your problem? 

    thanks

  • 0 in reply to J Yin
    TI__Mastermind 23000 points

    I was speaking specifically of execution from SRAM, which can be common during code development and debug.  If you set the PBIST to test SRAM which has your current program/stack, you will corrupt your execution context.  It is generally necessary then for a power-on reset or debugger reset to restart from scratch.

  • 0 in reply to KGreb
    Intellectual 295 points

    Yes, you are right. When you do PBIST, did you corrupt your current program/stack? or how to avoid it?

    Hi, Prathap

    Your program was not reset because there is no return in your function. The PBIST was run correctly and It reach while(1) but  the system stack was corrupted actually.

    I have asked in previous post that if the PBIST should work in this way?

  • 0 in reply to J Yin
    TI__Genius 14205 points

    Hi J Yin

    Yes when you perform PBIST on main RAM ( SRAM) the contents will be erased, hence your stack got corrupted. You need to backup the necessary inforamtion in RAM before triggering the SRAM PBIST test. Hence typically users do the SRAM PBIST test during the start up..

    There is an option to SWAP RAM and FLASH Base address ( i.e bringing RAM to address 0 and FLash to address 0x08000000). After Swapping you can load your code to RAM and run, ( Even the vector table is at RAM which is at address 0).  I think Karl has done this swapping, loaded the SRAM PBIST code to SRAM itself and Run hence ended up with problem.

    Best Regards
    Prathap