• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 868 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Is there any forbidden combinations of enabling/disabling PBIST?

Jules Patru
Intellectual 380 points
Other Parts Discussed in Thread: RM46L852

Hi, I am Jules from France and I am new in this forum.

I am currently developping a CAN driver based on DMA capabilities and I found some good examples somewhere in this forum ( e2e.ti.com/.../287665 ).

However, I observed some weird behavior I cannot explain; here are my exact problematic sequence:

  1. download the zip file from aforementioned link,
  2. unzip the file and import it in my CCS V6,
  3. change the project settings to use RM46L852 target, USB XDS100V2 debug probe and little endianness,
  4. change only the sys_startup.c file with following config (line 333):

pbistRun(  (uint32)0x00000000U    /* EMAC RAM */
                 | (uint32)0x00000000U    /* USB RAM */
                 | (uint32)0x00000800U    /* DMA RAM */
                 | (uint32)0x00000200U    /* VIM RAM */
                 | (uint32)0x00000040U    /* MIBSPI1 RAM */
                 | (uint32)0x00000080U    /* MIBSPI3 RAM */
                 | (uint32)0x00000100U    /* MIBSPI5 RAM */
                 | (uint32)0x00000000U    /* CAN1 RAM */
                 | (uint32)0x00000000U    /* CAN2 RAM */
                 | (uint32)0x00000000U    /* CAN3 RAM */
                 | (uint32)0x00000000U    /* ADC1 RAM */
                 | (uint32)0x00000000U    /* ADC2 RAM */
                 | (uint32)0x00000000U    /* HET1 RAM */
                 | (uint32)0x00000000U    /* HET2 RAM */
                 | (uint32)0x00000000U    /* HTU1 RAM */
                 | (uint32)0x00000000U    /* HTU2 RAM */
                 | (uint32)0x00000000U    /* RTP RAM */
                 | (uint32)0x00000000U    /* FRAY RAM */
                 ,(uint32) PBIST_March13N_DP);

Then compile the project, load it into the target, and launch the program.

--> Something is "broken", DMA is not working properly; dmaFTCAInterrupt function is never called again.
Issue is 100% reproducible.

Hence my question is :  Is DMA RAM PBIST using any of the latest peripheral (FRAY, RTP, HTU, HET, ADC) to perform its own checks and it is forbidden to enable DMA RAM PBIST and Disabling the other RAM tests?

Thanks for all

Jules

  • 0
    TI__Guru 59540 points
    Hello Jules,

    Welcome to the TI E2E. Hopefully you will find this format helpful!!

    In regard to your question regarding DMA_PBIST, the PBIST algorithms are completely independent of the other modules on the device. i.e., the PBIST only acts on the module to which you are initiating it. There are some algorithms available that are only recommended for single-port RAMs and some for Dual-port RAMs, but these are generally not recommended for use in an application. We typically recommend the March13N algorithms which do not have a dependency on the type of RAM.

    Does the example code execute correctly when you remove the DMA PBIST? If not, then it might be an endianess issue given the example was developed for a big endian device and there may be some code that is not little endian friendly.
  • 0 in reply to Chuck Davenport
    Intellectual 380 points

    Hello Chuck,

    Thanks for your answer and sorry for late reply.

    I performed a bit more tests and here are the results:

    1. When all pbist are enabled, program behaves as per expectations,
    2. When all pbist are disabled, programl behaves as per expectations,

    I also performed more tests using the first post configuration:

    1. If I use this pbist configuration, as I told, DMA is not working well anymore,
    2. If I use this problematic pbist configuration + enabling of one of the 7 latest pbist (ADC2, HET1, HET2, HTU1, HTU2, RTP, FRAY), program is back to normal behavior !!! Issue is not visible anymore

    Hence, to answer to your question, I can disable the DMA pbist and see the application working fine, yes...

    I am really confused... and do not undertand what could happen.

    Thanks

    Jules

  • 0 in reply to Jules Patru
    TI__Guru 59540 points
    Hello Jules,

    I know that the project you are working with was pulled from the example in the other thread, but could you zip and post your version of the project so I can have a look at it?
  • 0 in reply to Chuck Davenport
    Intellectual 380 points

    Hi Chuck,

    Please find the exported project as attachment.
    Just take care that:

    • I commented the enableLoopback instruction and manually send CAN frame with a CAN tool (canalyser type),
    • The exported project does contain the issueing sys_startup.c file.

    Thanks for help!

    PS: Chuck, I also noticed that you are already involved in another thread that looks like similar to the issue I can see:


    Jules1157.CAN+DMA_With_Issueing_sysstartup.zip

  • 0 in reply to Jules Patru
    TI__Mastermind 22715 points

    Julles,

    For some peripheral RAMs (including the DMA control packet RAM, not all ), value in the the Memory Self-Test Global Control (MSTGCR)  register in the system module needs to be toggled for CPU to access the RAM after the completion of the PBIST test. In your original test, you can see that CPU cannot write to the DMA control packet RAM after the PBIST test. You solve this issue by modifying the pbistStop function as follows.

    void pbistStop(void)
    {
    /* USER CODE BEGIN (20) */
    /* USER CODE END */
        /* disable pbist clocks and ROM clock */
        unsigned int temp;
        pbistREG->PACT = 0x0U;
        temp = systemREG1->MSTGCR;
        temp &= ~(0xFU);
        temp |= 5;
        systemREG1->MSTGCR = temp;
        temp &= ~(0xFU);
        temp |= 0xA;
        systemREG1->MSTGCR = temp;
        temp &= ~(0xFU);
        temp |= 5;
       systemREG1->MSTGCR = temp;
    /* USER CODE BEGIN (21) */
    /* USER CODE END */
    }

    I will also notify the PBIST team so that they can make the change in the future release.

    Thanks and regards,

    Zhaohong

  • 0 in reply to Zhaohong Zhang
    Intellectual 380 points

    Hello, 


    I have just spent some time to test the workaround you provided, and it looks like solving my issue...

    However, I am still wondering something about your post; I am not able to find neither in RM46x Technical Reference Guide, nor in RM46 datasheet nor in microcontroller errata sheets any reference to this requested toggling sequence.

    I assume i missed it... could you just please tell me where this is noted down?

    Thanks for help.

  • 0 in reply to Jules Patru
    TI__Mastermind 22715 points
    There was discussion a couple of years ago to clarify this behavior in either TRM or errata. It seems that it got lost in the process. We will need to start it again. Thanks for pointing it out.

    Thanks and regards,

    Zhaohong
  • 0 in reply to Zhaohong Zhang
    Intellectual 380 points
    Thanks for help.
    Now it's clear to me.