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.
Hello Anthony
It is the same example from HALCoGen that you are mentioning. I've followed the instructions mentioned in the example
"Add all the files in the folder "<SL installation path>\safety_library\source" in the project
* Include the following directories to #include search path
* - "${workspace_loc:/${ProjName}/include}"
* - "${workspace_loc:/${ProjName}/<folder where SL files are added>}"
* - "<SL installation path>\hal\include"
* - "<SL installation path>\safety_library\include"
*
* @b Step @b 3:
*
* Add the following macros (without quotes) as predefined symbols to the project (Project Properties->CCS Build->ARM Compiler->Advanced Options->Predefined Symbols):
* - "_TMS570LC43x_" (or "_RM57Lx_" based on the device)
* - "_VFP_SUPPORT_=1"
* - "EXTERNAL_SP_INIT"
*
* @b Step @b 4:
*
* Add the following in the SECTIONS block in the linker command file
*
* LOG_DATA : START( ulLOGStartAddr ), END( ulLOGEndAddr ) > RAM
*
* .sl_stflash_SRAM : RUN = RAM, LOAD = FLASH0|FLASH1, LOAD_START(ulHighHandlerLoadStart), LOAD_END(ulHighHandlerLoadEnd), LOAD_SIZE(ulHighHandlerSize), RUN_START( ulHighHandlerStartAddr ), RUN_END( ulHighHandlerEndAddr ) "
To your question "What exactly are you seeing as a problem?"
The test doesn't progress from the PBIST ROM test as it enters while(1); as SL_SelfTest_PBIST() returns FALSE due to nERROR active. The status registers show that the errors are 1)CCM-R5F Self Test
2)CPU Interconnect Subsystem - Global error
Does errata DEVICE#48 and #49 has anything to do with this code?
Hello Anthony,
Is there a workaround for this known issue? What code has to be added and where to add the code?
I also see that the Error pin doesn't reset after Errkey is written with 0x5.
Sindhu,
The exampleSafetyLib.c code is only an example showing how to call the API's. It's like the other example code - it's not necessarily robust.
In this case there is an issue in just doing while(1) if that call returns an error because of the nERROR pin.
The ERRKEY sometimes needs to be written 0xA then 0x5 or else the pin won't clear. We aren't sure why exactly but seems like this has to do w. reset.
I have another query regarding the same code. For VIM RAM, the PBIST test is done as follows in the HalCoGen example
#if PBIST_VIM_ENABLE == 1
{
boolean retVal;
SL_PBIST_FailInfo pbistStatus;
/* Start PBIST on STC and PBIST ROM */
retVal = SL_SelfTest_PBIST( PBIST_EXECUTE,
PBIST_RAMGROUP_01_PBIST_ROM |
PBIST_RAMGROUP_02_STC1_1_ROM_R5 |
PBIST_RAMGROUP_03_STC1_2_ROM_R5 |
PBIST_RAMGROUP_04_STC2_ROM_NHET,
PBISTALGO_TRIPLE_READ_FAST_READ |
PBISTALGO_TRIPLE_READ_SLOW_READ);
if(retVal == false){while(1);}
/* Wait for PBIST on ROM to complete */
while(SL_SelfTest_Status_PBIST(&pbistStatus) == FALSE);
SL_SelfTest_PBIST_StopExec();
if(pbistStatus.stResult != ST_PASS)
{
/* PBIST fail */
while(1);
}
/* Clear VIM pending interrupt request (Channel 85 - PBIST Done) */
vimREG->INTREQ2 = 0x00200000;
}
#endif
Why is the PBIST RAM selection parameter( the second parameter passed to SL_SelfTest_PBIST() ) for VIM RAM testing is PBIST and STC ROM group ?