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.

RM44L920: PSCON PMA Self-Test fail

Part Number: RM44L920

Tool/software:

Hello,

I implemented the PSCON PMA test using the SDL API within a diagnostic task. The self-tests and error-forcing tests are working fine, except the PSCON test, which gets stuck in a loop and never completes.

According to the SDL documentation, this test must be executed in USER mode, which I confirmed is the case during execution.

During debugging, I noticed a data abort occurs as expected when attempting the following illegal access:

/* Try writing to GLOBALCTRL1.AUTO_CLK_WAKE_ENA, which should result in an abort*/
sl_pmmREG->PRCKEYREG = 0x0000000FU;

However, in the data abort exception handler, the maskDAbort flag is not set to TRUE as expected. This is because the faulting address is reported as 0xFFFF00AC, and the handler doesn't recognize this fault as part of the intended test behavior.

/*
 * DAbort due to access to  PMM global control register (sl_pmmREG->GLOBALCTRL1) access in user mode?
 * 0x00000009 indicates that it is an external abort caused by read and is AXI decode error
 * 0xFD000000 is the reserved location accessed to create the L2 interconnect error trap AXI decode error
 */
if ((TRUE == SL_FLAG_GET(PSCON_PMA_TEST)) &&
	((0x00000800u == (0x0000800u & _SL_Get_DataFault_Status())) &&
	(0xFFFF00A0 == _SL_Get_DataFault_Address()))){
	maskDAbort = TRUE;
}

there is another data abort when this line runs, and fault address is reported as 0x00000000F.

if(regbackup == sl_pmmREG->PRCKEYREG)

and another data abort here:

 /* Revert to normal operation */
sl_pmmREG->PRCKEYREG = PMM_PRCKEYREG_MKEY_LKSTEP_MODE;

Any guidance on how to properly handle and execute PMA test.

Thanks & regards,

Ilija

  • Hi Ilija,

    My sincere apologies for the delayed response, i was stuck with other issues in this mean time.

    Are you still stuck with this issue, do i need to debug this issue at my end?

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Yes I am still facing the issue and I’d appreciate it if you could help debug the issue on your end as quickly as possible.

    Thank you.

    Ilija

  • Hi Ilija,

    I am in debugging and couldn't find any root cause yet, please give me some time to update the results. I will try to update by this weekend.

    --
    Thanks & regards,
    Jagadish.

  • Hi Ilija,

    I tested it today, as i don't have RM44x board with me i tested it on RM46x.

    And on my testing i didn't get any data abort however i got the ST_PASS results.

    And then i found the below thread of my senior colleague:

    (18) TMDS570LS31HDK: PMM/PSCON Data abort injection test passes without aborting. - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

    As mentioned here the comment is misleading here, here we don't get any data abort for this testing.

    --
    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    Thank you for your response.

    However, your answer doesn't really clarify things for me. I'm still unsure how the PSCON PMA test is supposed to be performed correctly. Isn’t the whole point of the test to trigger a data abort and then have it properly masked and handled?

    In my case, what happens is that the system seems to get stuck and continuously executing the test without progressing. Could you please explain how this test is actually supposed to work and what the expected behavior is?

    Thanks & regards,

    Ilija

  • Hi Ilija,

    However, your answer doesn't really clarify things for me. I'm still unsure how the PSCON PMA test is supposed to be performed correctly. Isn’t the whole point of the test to trigger a data abort and then have it properly masked and handled?

    No, the whole point of the test is not to trigger the data abort. The main objective of the test is to any write in PRCKEYREG register in user mode should not take effect. 

    So, this is the reason they are backing-up the value of the register before writing, and then they are performing the writing with some other value like 0x0000000F and then they are comparing this register value with backup value. If current register value is equal to the back-up value means, there is no write taken place as we are writing in the user mode.

    In my case, what happens is that the system seems to get stuck and continuously executing the test without progressing. Could you please explain how this test is actually supposed to work and what the expected behavior is?

    On my end it worked.

    Can you please verify your project with mine once:

    PSCON_PMA_TEST_RM46.zip

    Thanks & regards,
    Jagadish.

  • Hi Jagadish,

    I checked your project example, but I kindly ask you to take another look at my original question.

    I also get a test pass, however I encounter a data abort at other points in the code — for example, when the PMM is returning to normal operating mode, you don't have that in your example, as a matter of fact you don't use SL_SelfTest_PSCON() function from SDL. 

    I saw in the TRM that this register(PRCKEYREG) can only be written to in privileged mode. Could this be the cause of the error? And should the ARM mode perhaps be switched from user mode to a privileged mode before this?

    Thanks & regards,

    Ilija

  • Hi Ilija,

    I saw in the TRM that this register(PRCKEYREG) can only be written to in privileged mode. Could this be the cause of the error? And should the ARM mode perhaps be switched from user mode to a privileged mode before this?

    You are totally correct about this, i mean if any register has privilege write then we should only write into that register in privilege mode only. If we write in user mode, then those write will generate abort.

    However, my senior colleague (QJ wang) found that this is not applicable for this register as per the thread i shared to you. In that thread they found only writes will not taking place, but abort is not generated for writing in PRCKEYREG. This is what their conclusion.

    If you want i can again check with QJ once regarding this and will cross confirm it again.

    --
    Thanks & regards,
    Jagadish.