RM46L430: Safety Manual states that RAM7A & RAM7B are covered by SL_SelfTest_PBIST, but SL_SelfTest_PBIST cannot be run the TCRAM as running the test corrupts the 'C' runtime system

Hi Mark,

The PBIST is usually run on device start-up as it is a destructive test and all contents of the tested SRAM module are overwritten during the test. The SRAM are divided into several groups, and you can place your data and instructions in one SRAM group, and test other SRAM groups. Another way, you can copy the data to the RAM of unused peripheral (for example CAN1 RAM) and restore those important data back to SRAM after PBIST.

Mark,

To add to QJ's comments, RAM7A and 7B indicate boot time and periodic execution of PBIST. Running PBIST on SRAM, as you note, is destructive and should be done only at boot time since it is unlikely that you will find another RAM in the device that you could use to back up your data/runtime information during a PBIST execution executed periodically. For some devices, the SRAM is broken into different sections so that PBIST could theoretically be ran on one while another is used for backup, but even this is difficult to manage due to dependencies of the SW on RAM accesses that are beyond user control. To combat this, I would recommend implementing the code as inline code during boot time so that the Stack isn't needed/used.

In addition, if the application is such that it has relatively short ON times (automotive applications, for example) ECC is sufficient to protect against single point faults and latent faults are unlikely during runtime. If, however, your application is an industrial or other application such that ON times are very long (Days, weeks, even years) without a power cycle, latent faults become an issue since the possibility of a fault on demand would increase. In these cases, there may be a need to include the concept of a maintenance cycle where the unit is power cycled or soft reset at a regular, specified interval in time (once/wk, once/year... depends on the application needs). This interval could also, arguably, be considered a periodic test. This same concept also applies towards LBIST execution.

Hi,

There multiple steps to the testing the TC RAM via the SafetTI Diagnostics Library and they are all written in 'C'.

You call a 'C' fucntion to start the test (SL_SelfTest_PBIST), which uses the stack and starts the hardware mechanism. An overview of the SL_SelfTest_PBIST functionality is:

1. Save the return value (Link Register) on the stack.
2. Initial the PBIST mechanism.
3. Start the PBIST.
4. Use the Link Register from the stack to return to the caller.

The start of SL_SelfTest_PBIST, notice the STMBD saving the R14 (Link Register) to the R13 (Stack Pointer):

/*SAFETYMCUSW 61 D MR: 8.10,8.11 <APPROVED> Comment_15*/
/*SAFETYMCUSW 7 C MR: 14.7 <APPROVED> Comment_3*/
/*SAFETYMCUSW 62 D MR: 16.7 <APPROVED> Comment_17*/
#if defined(_TMS570LC43x_) || defined(_RM57Lx_)
boolean SL_SelfTest_PBIST (register SL_SelfTestType testType, register uint64 ramGroup, register uint32 algoInfo)
#else
boolean SL_SelfTest_PBIST (register SL_SelfTestType testType, register uint32 ramGroup, register uint32 algoInfo)
#endif
{
  0x0000ADA8:   E92D41FC     STMDB     R13!,{R2-R8,R14}
> 0x0000ADB8:   E1A04000     MOV       R4,R0
> 0x0000ADBC:   E1A07001     MOV       R7,R1
> 0x0000ADC0:   E1A06002     MOV       R6,R2

The end of SL_SelfTest_PBIST, notice the LDMIA, restoring the Link Register directly to R15 (Program Counter) from R13 (Stack pointer) to return to the caller:

            /* Start PBIST */
            /* Note: If executing on TCM RAM, Stack Contents are corrupted, so be careful with return data */
            /*SAFETYMCUSW 440 S MR: 11.3 <APPROVED> Comment_18*/
            sl_pbistREG->DLR = (PBIST_DLR_DLR4 | PBIST_DLR_DLR2);
  0x0000AED4:   E3A0C014     MOV       R12,#0x14
  0x0000AED8:   E585C000     STR       R12,[R5,#0x0]
  0x0000AEDC:   E8BD81FC     LDMIA     R13!,{R2-R8,R15}
  ...
            retVal = TRUE;
         break;
        default:
        	/* nothing here - comment to avoid misra-c warning */
            break;
    }
#if(FUNC_RESULT_LOG_ENABLED == 1)
    SL_Log_Result(FUNC_ID_ST_PBIST, testType, (SL_SelfTest_Result)retVal , 0u);
#endif
    return(retVal);
}

This clearly shows that the stack is being used after the hardware test has been started. Now, I'm sure that you will argue that there is only a small chance that the test will have corrupted the stack before it can return, which is most likley true (although very poor design), but there is another 'C' function that needs to be polled to get the result, SL_SelfTest_Status_PBIST, which also uses the stack.

Again, the start of SL_SelfTest_Status_PBIST, notice the STMBD saving the R14 (Link Register) to the R13 (Stack pointer) to return to the caller:

/*SAFETYMCUSW 61 D MR: 8.10,8.11 <APPROVED> Comment_15*/
/*SAFETYMCUSW 7 C MR: 14.7 <APPROVED> Comment_3*/
boolean SL_SelfTest_Status_PBIST(SL_PBIST_FailInfo* param1)
{
  0x0000A594:   E92D4038     STMDB     R13!,{R3-R5,R14}
  0x0000A598:   E1A04000     MOV       R4,R0
	boolean retVal = FALSE;
	boolean tmp;
#ifdef FUNCTION_PARAM_CHECK_ENABLED
    /*LDRA_INSPECTWINDOW 50 */
    /*SAFETYMCUSW 439 S MR:11.3 <APPROVED> Comment_4*/
    /*SAFETYMCUSW 439 S MR:11.3 <APPROVED> Comment_4*/

The end of SL_SelfTest_Status_PBIST, notice the LDMIA,  restoring the Link Register directly to R15 (Program counter) to return to the caller:

#if(FUNC_RESULT_LOG_ENABLED == 1)
        /*SAFETYMCUSW 440 S MR: 11.3 <APPROVED> Comment_18*/
        SL_Log_Result(FUNC_ID_ST_PBIST_STATUS, (SL_SelfTestType)0, param1->stResult, 0u);
#endif
        }
        retVal = TRUE;
    return retVal;
  0x0000A660:   E3A00001     MOV       R0,#0x1
  0x0000A664:   E8BD8038     LDMIA     R13!,{R3-R5,R15}
  ...
}

So, one again to clarify my concerns about this mechanism:

Whilst the test is running, the test status is being polled by a 'C' function that is using the stack which is corrupted by the running hardware test.

I do no understand you comment 'Another way, you can copy the data to the RAM of unused peripheral'. This is the stack that is being used by the 'C' runtime system, how can it be saved to a peripheral memory, the stack is used for each function call!

The satement in the Safety Manual that RAM7A & RAM7B are covered by calling SL_SelfTest_PBIST is not true.

The Demo application from the SafeTI Diagnostics Library does not even call SL_SelfTest_PBIST with any of the ESRAM enumerate literals, which I guess is because it just crashes!

If I missunderstand the whole 'C' runtime mechanism and the implementation of the SL_SelfTest_PBIST & SL_SelfTest_Status_PBIST, then please provide me with an example of how I can run the test on the TCRAM using the mechanism as described in the Safety Manual.

Hi Mark,

The stack issue is a known issue. There is even a note in the code indicating that care has to be taken regarding the return value from the function. Even with this comment, though, it really isn't a desirable situation to have this as a function call since it will still use the STACK and, as you pointed to about, the call to the logging function adds further issue on top of the problematic implementation. A CQ ticket has been raised for this so it can be addressed in the next release.

My comments previously were that the functions that are called could be potentially declared as inline which would eliminate the stack use and that there is some potential that other RAMs on the device could be used to back up data. I also noted that this would be difficult to impossible for any runtime related information. For the case of calling this function at boot time, you could certainly back up the stack to one of the RAM locations before instantiating the PBIST and then restore it before returning (after assuring the PBIST execution is not ongoing).

Note that your second example, is not an issue with the STACK since this function, SL_SelfTest_Status_PBIST, is only accessing the registers and returning the status. PBIST would/should not be active during the call to this function other wise it wouldn't return the correct status update.

In regard to the Safety Manual, I understand now that you are referring to the SafeTI Diag Library Safety Manual and not necessarily the Device Safety Manual. I believe the intent was that the function satisfy the boot or periodic execution of PBIST. For sure, Boot time execution is possible with some care. Periodic execution would prove to be too difficult unless you plan to initiate a warm reset or some other 'restart' where the boot time would be come periodic. For the cases where there is long term need for RAM use we rely on the ECC and it's secondary diagnostics as well as the RAM Bit Multiplexing implementation to protect memory content. i.e., virtually all errors in RAM will be single bit errors and ECC will correct these on the fly with no impact to the applications.

Hi Mark,

Clearly you are frustrated and I understand this have spent time also looking through the code. Yes, the code is a problem and needs to be repaired. This is why I stated there is an open ticket on it to be repaired in the next release.

Without any further explanation or excuse for the software, I believe your choice to implement the boot time PBIST as you have done is the optimum way to implement it and really fits best with the vision we had when we identified this as a safety mechanism.

My apologies for the confusion and for any grief the poorly thought through PBIST implementation in the safety diagnostic library may have caused you.