RM57L843: RM57L843

user5090366

Part Number: RM57L843

1.When choose RAM group 29 and 30, L2RAMW, does it meant PBIST will test the set of registers?

2.According to RM57Lx 16_32 RISC Flash Microcontroller Technical Reference Manual & RM57L843 Hercules™ Microcontroller Based on the ARM® Cortex®-R Core (Rev. C), there is only one set of L2RAMW registers which start at 0xFFFFF900U, why RAM group 29 and 30 are all L2RAMW, what is the difference?

3.When choose RAM group 30, after PBIST, data abort occured, but the result of PBIST itself is right. Why would this happen? How to deal with it?

4.What are RGS & RDS for?

over 6 years ago

0 Chuck Davenport over 6 years ago

TI__Guru 59540 points

Hello User,

user5090366 said:

1.When choose RAM group 29 and 30, L2RAMW, does it meant PBIST will test the set of registers?

2.According to RM57Lx 16_32 RISC Flash Microcontroller Technical Reference Manual & RM57L843 Hercules™ Microcontroller Based on the ARM® Cortex®-R Core (Rev. C), there is only one set of L2RAMW registers which start at 0xFFFFF900U, why RAM group 29 and 30 are all L2RAMW, what is the difference?

As noted in the datasheet, there are multiple RAMs located throughout the device. The primary RAM (SRAM) is devided into 2 "banks" of memory with each having half of the total SRAM available. Each one of these is identified as a "RAM Group" that PBIST can execute its test engine on. These can be selected together so all SRAM is tested at once during one PBIST run or separately so half is tested at any given time. This is sometimes needed if there is data that needs to be preserved since PBIST test is a destructive test. Note that this is actual memory and not the registers of the ram wrapper itself.

user5090366 said:
3.When choose RAM group 30, after PBIST, data abort occured, but the result of PBIST itself is right. Why would this happen? How to deal with it?

This is, most likely, a result of the destructive nature of the PBIST algorithm causing the stack to be corrupted. i.e., the stack is probably located in the same memory range as RAM group 30 causing an indeterminate value in the return address stored on the stack. It is recommended to load and run PBIST at boot time only as this lessens the complications of maintaining the stack and other RAM content that needs to be preserved. If it is required to run PBIST during the application, it would be necessary to devise a management scheme where the data in the RAM Group under test is backed up prior to the test then restored after.

user5090366 said:
4.What are RGS & RDS for?

These two posts do a fairly good job at explaining RGS:RDS.

0 user5090366 over 6 years ago in reply to Chuck Davenport

Prodigy 100 points

According to RM57Lx 16_32 RISC Flash Microcontroller Technical Reference Manual, RAM Group # of STC1_1_ROM_R5 is 2, but RGS of STC1_1_ROM_R5 is 14, why they are different?

0 user5090366 over 6 years ago in reply to Chuck Davenport

Prodigy 100 points

Thank you for your answers, they are very helpful. The reason of data abort is not the stack has been corrupted. It is because some global data been allocated in the RAM between 0x08020000 to 0x08080000. The global data been corrupted after PBIST. I want to reset them to be 0 and I have checked RAM between 0x08020000 to 0x08080000, they are all 0 without PBIST. The problem is I can't change the value even after disabling PBIST by calling boolean SL_SelfTest_PBIST_StopExec(void). Why would this happen? How to deal with it?

0 Chuck Davenport over 6 years ago in reply to user5090366

TI__Guru 59540 points

Hello User,

First, I would recommend that you run PBIST before initializing the global data this way it will not be a problem with it being overwritten. If there is a need to provide assurance of RAM integrity over long periods of time as is often the case with industrial applications, my recommendation is to argue that ECC is protecting the safety goal 100% of the time after the initial boot time PBIST check. Also note that there is also ECC proof of function tests that should be ran on a periodic basis and also the ECC logic is included with the CPU lockstep mechanism so it is also protected by the lockstep CPU safety mechanism.

WIth that said, are you using the SafeTI Diagnostic Library to execute PBIST or some other code that you have created. Can you post your code so I can have a look at it?

Another factor that may be coming into play is the use of Cache. If you are modifying these memory locations and they are located in Cache memory, you may not see your updates in actual RAM. To be certain, you could configure these memory regions as write through and that way they will be immediately updated.

0 user5090366 over 6 years ago in reply to Chuck Davenport

Prodigy 100 points

static boolean RamGroupTest(register uint64 ramGroup, register uint32 algoInfo, SL_PBIST_FailInfo* param1)
{
    boolean ret = FALSE;
	ret = SL_SelfTest_PBIST(PBIST_EXECUTE, ramGroup, algoInfo);
	if(ret == TRUE){
		while((sl_systemREG1->MSTCGSTAT & 0x1u) == 0x0u);
		ret = SL_SelfTest_Status_PBIST(param1);
	} else {
		return ret;
	}
	return ret;
}

boolean RamTest(void)
{
    boolean ret = TRUE;
	ret = RamGroupTest(0x000000000000000f, 0x00000001, &RamTestParam[0]);
	ret = ret && RamGroupTest(0x000000000000000f, 0x00000002, &RamTestParam[1]);
	ret = ret && RamGroupTest(0x000000000cffbff0, 0x00000004, &RamTestParam[2]);
	ret = ret && RamGroupTest(0x00000018e0000000, 0x00000008, &RamTestParam[3]);
	return ret;
}

/* MACROS / Constant Definitions **********************************/
#define STACK_BASE						0x08000000
#define STACK_SIZE						(0x08003400 - 0x08000000)
#define RAM_REGION_BASE					0x08003400
#define RAM_REGION_SIZE					(0x08080000 - 0x08003400)

#if 1 
#define RAM_BACKUP_LENGTH				(RAM_REGION_SIZE >> 2)
/* Private variables */
PBIST_DATA_SECTION uint32 RamBackup[RAM_BACKUP_LENGTH] = {0};//locate in Dram from 0x80000000 to 0x81FFFFFF
#endif

void CleanRam(void)
{ 
	volatile uint32* i = (uint32*)0x08020000;
	while((uint32)i < 0x08080000){
		*i = 0;
		i++;
	}	
}

void StoreRam(void)
{
	volatile uint32* i = (uint32*)0x08020000;
	while((uint32)i < 0x08080000){
		RamBackup[((uint32)i - 0x08003400) >> 2] = *i;
		i++;
	}	
}

void RestoreRam(void)
{
	volatile uint32* i = (uint32*)0x08020000;
	while((uint32)i < 0x08080000){
		*i = RamBackup[((uint32)i - 0x08003400) >> 2];
		i++;
	}	
}

Cache has been disabled until SafeRTOS has been started.

Arm-based microcontrollers

Arm-based microcontrollers forum

RM57L843: RM57L843