TMS320F28388D: non master CLA read violation

Hello,

Just to clarify, you made changes to the f2838x_ram_access_protect_ram_lnk_cpu1.cmd file, is that correct? If you try the power cycle with the original linker cmd file, do you see the same issue?

Best Regards,

Delaney

Hello,

sorry it was failure from my side. I did not pay attention that CLA can run code only from RAM. I copied the code from flash to RAM and CLA task can run and the test functions correctly.

Another question related to the non master CLA read violation. In the test code from TI it is harded coded in the CLA task that a variable is read. For reference, the code is pasted here.

For example, during the run time before the test run, lsDataPtr can be assigned with starting address of LS0, 0x00008000, then the LS0 RAM is configured to be CPU only. When the test runs, the expectation is the CLA reads the content at 0x00008000 and non master CLA read violation is triggered. But the violation is not triggered. 

What is the reason? 

Thanks. 

Hello,

Glad you were able to resolve the original issue. You are correct, the CLA must run code from an LSRAM that it has access to. For the F2838x, the CLA's have access to all the LSRAMs 1-7 (this information can be found in the Functional Block Diagram of the device datasheet). 

Which example code are you showing here? Can you provide the C2000ware path, and I will take a look?

Best Regards,

Delaney

c2000\C2000Ware_4_01_00_00_STL\libraries\diagnostic\f2838x\examples\sdl_ex_ram_access_protect\f2838x_sdl_ex_ram_access_cla_read.cla

Hi Chao,

Thank you, I will take a look and get back to you.

Best Regards,

Delaney

I think this method should work. Can you share the CPU side of this code showing how lsDataPtr is updated and how the RAM access modes are configured? If the CPU is responsible to update the address lsDataPtr is pointing to, is the lsDataPtr variable itself located in a shared memory where the CLA can access it (but of course not the data it's pointing to)?

Whitney

hello, follow shows roughly how the code works:

/template.c:
typedef struct
{
uint8_t violationType; /*!< stores the type of test */
uint32_t* violationStartAddress; /*!< stores the address where the violation is tested. */
FunctionPtr functionPtr; /*!< CLA Task function ptr */
} config_T;

/templateCLA.cla:
extern volatile uint32_t* lsDataPtr;

/* Cla1Task - Task code to do a read of a variable to which it shouldn't have access. */

__attribute__((interrupt)) void Cla1Task(void)
{
uint32_t test;
test = *lsDataPtr;
test++;
}

/setup.c:
#pragma DATA_SECTION(lsDataPtr, "in LS7 data memory")
volatile uint32_t* lsDataPtr;

config_T LS0Setup =
{
.violationType = Non Master CLA Read Violation,
.violationStartAddress = lsDataPtr,
functionPtr = Cla1Task;
}

config_T LS1Setup =
{
.violationType = Non Master CLA Read Violation,
.violationStartAddress = lsDataPtr,
functionPtr = Cla1Task;
}
.
.
.

void NMCLAReadPreHook()
{
switch(whichLSSection)
{
config LS7 as CLA data memory();
config related LS as CLA scratchpad();
config related LS as CLA programm memory();
case LS0:
lsDataPtr = (uint32_t*)((uintptr_t)(0x00008000UL));
config LS0 to be CPU only();
break;
case LS1:
lsDataPtr = (uint32_t*)((uintptr_t)(0x00008800UL));
config LS1 to be CPU only();
break;
...
default:
break;
}
}

void runTest()
{
/* */
}

/main.c:
void main(){
based on the config(LS0Setup, LS1Setup....) decide variable whichLSSection();
NMCLAReadPreHook();
register Cla1Task CLA task1();
software trigger CLA task1();
}

I'm not spotting any issues with this structure. Are you able to put a breakpoint in the CLA task and confirm that it's executing as expected?

Whitney