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.

TMDS570LS31HDK: PMM/PSCON Data abort injection test passes without aborting.

Part Number: TMDS570LS31HDK
Other Parts Discussed in Thread: HALCOGEN, TMS570LC4357, TMS570LS3137

When implementing the SafeTI SDL PSCON selftest "PSCON_PMA_TEST" I am noticing a bug, similar to the related thread.

When in user mode, the test writes to GLOBALCTRL1.AUTO_CLK_WAKE_ENA expecting an abort, then compares the value of the register before the bad write and after to ensure it was not modified.

In testing, writing to the register does not change the value, however no data abort or otherwise is triggered. The test passes because the register was unmodified, but this fails to test the actual abort behaviour.

Is there any reason why this would happen? 

  • Hi Robin,

    We started working on your issue and we will provide an update soon.

    --
    Thanks & regards,
    Jagadish.

  • Hi Robin,

    Do you have any tested code, can you please attach the code once for easy triggering of issue at my end?

    --

    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Unfortunately I cannot share the whole source, but I can share more about what tests are happening.

    The following line in the sl_selftest.c file is the one that is intended to trigger the dabort:

    Of note, the PRCKEYREG being set above is actually already set to 0x0 before this line is called:

    We can see this in the regbackup variable on line 2459 being set to 0x0 as well:

    I'm wondering if I'm missing some sort of setup step? In the main program I call the HALCoGen default sys_startup with all tests enabled:

    I then just call the suite of SafeTI test functions after this startup is finished. For the PMM:

    bool runSafeTiPsconTests() {
        bool slRet = false;
        SL_SelfTest_Result failInfoPscon = ST_FAIL;     /* PSCON Failure information. */
    
        /* Run PSCON selftest Error Forcing test. */
        slRet = SL_SelfTest_PSCON(PSCON_SELF_TEST_ERROR_FORCING, true, &failInfoPscon);
        if ( (slRet != true) || (failInfoPscon != ST_PASS) ) {
            return false;
        }
    
        /* Stop PBIST Execution. */
        slRet = SL_SelfTest_PBIST_StopExec();
        if (slRet != true) {
            return false;
        }
    
        /* Run PSCON selftest Error Forcing Fault Injection test. */
        slRet = SL_SelfTest_PSCON(PSCON_SELF_TEST_ERROR_FORCING_FAULT_INJECT , true, &failInfoPscon);
        if ( (slRet != true) || (failInfoPscon != ST_PASS) ) {
            return false;
        }   
    
        /* Stop PBIST Execution. */
        slRet = SL_SelfTest_PBIST_StopExec();
        if (slRet != true) {
            return false;
        }
    
        /* Run PSCON Error forcing test. */
        slRet = SL_SelfTest_PSCON(PSCON_ERROR_FORCING, true, &failInfoPscon);
        if ( (slRet != true) || (failInfoPscon != ST_PASS) ) {
            return false;
        }
    
        /* Stop PBIST Execution. */
        slRet = SL_SelfTest_PBIST_StopExec();
        if (slRet != true) {
            return false;
        }
    
        /* Run PSCON Error Forcing Fault Injection test. */
        slRet = SL_SelfTest_PSCON(PSCON_ERROR_FORCING_FAULT_INJECT, true, &failInfoPscon);
        if ( (slRet != true) || (failInfoPscon != ST_PASS) ) {
            return false;
        }
    
        /* Stop PBIST Execution. */
        slRet = SL_SelfTest_PBIST_StopExec();
        if (slRet != true) {
            return false;
        }
    
        /* Run PSCON Privilege Mode User Access test.
         * Test tries to write to GLOBALCTRL1->AUTO_CLK_WAKE_ENA while in user mode. Should trigger an abort.
         * Checks to see if the register was written to and restores state.
         * Tests whether the PSCON can detect an user access violation.
         */
        /* This test requires user mode. System mode is restored from the dabort interrupt. */
        /* USER MODE BEGIN */
        portSWITCH_TO_USER_MODE();
        slRet = SL_SelfTest_PSCON(PSCON_PMA_TEST, true, &failInfoPscon); //! passes but does not actually abort
        /* USER MODE END */
        if ( (slRet != true) || (failInfoPscon != ST_PASS) ) {
            return false;
        }
    
        /* Stop PBIST Execution. */
        slRet = SL_SelfTest_PBIST_StopExec();
        if (slRet != true) {
            return false;
        }
    
        clearSafeTiFlags();
    
        /* All tests passed. */
        return true;
    }


    All other tests pass before this. Is there a setup step I'm missing? Thanks.

  • Hi Robin,

    Thanks for sharing all the details, i will test and provide you update.

    --

    Thanks & regards,
    Jagadish.

  • Hi Robin,

    I could see the issue you mentioned in TMS570LS3137, and i also verified with TMS570LC4357 there i can see the "_dabort" exception while writing but in TMS570LS3137 i could not see this exception.

    Let me analyzer further before providing update.

    --

    Thanks & regards,
    Jagadish.

  • Hi Jagadish, thanks for the response on this. Are there any updates to this?

  • Hi Robin,

    Are there any updates to this?

    Not yet Robin, give me some more time for analysis.

    --

    Thanks & regards,
    Jagadish.

  • Hi Jagadish, checking in on this item. Thanks!

  • Hi Jagadish, checking in on the analysis. Thanks!

  • Hi Robin,

    Your observation is correct. Writing to WP bit of PMM register in user mode will not generate abort.

  • Hi QJ,

    Thanks for the reply. What would be the workaround for this then? Ideally we'd like to avoid modifying the SafeTI source as this would prevent us from easily certifying the code.

  • sl_pmmREG->PRCKEYREG = 0x0000000FU; will not change the value of this register. No workaround is required. 

  • So in that case is the comment incorrect in the test? In the screenshot in the initial post the write to GLOBALCTRL1.AUTO_CLK_WAKE_ENA should trigger an abort, but doesn't. Because we drop to user mode for this test, we need to use the interrupt to reset our privilege after the test.

  • So in that case is the comment incorrect in the test?

    You are right. The comment in SDL is not correct. I'm sorry for this misleading comment. 

    Because we drop to user mode for this test, we need to use the interrupt to reset our privilege after the test.

    Yes, switching from user to privilege must be happened in an ISR.

  • Thanks for the clarification QJ! Appreciate it.