L2RAMW ECC enable

Hi Laura,

This page gives an explanation for CCS: processors.wiki.ti.com/.../LAUNCHXL2-570LC43-RM57L:_TIPS
and the TI compiler.

I'm not sure about LauterBach. Which compiler are you using?

-Anthony

I'm calling arm compiler version 5.1.10 from a makefile executed in cygwin.
I'm interested in the SRAM ECC located in
eccRAM (RW) : origin=0x08400000 length=0x00080000 /* 512K of ECC */
but reads from this address range result in a DataEntry interrupt

The newer versions of Lauterbach (11 May 206) initialize the Flash ECC with the regular old Lauterbach commands.

Hi Laura,

I don't have Lauterbach tools to try out so I can't help you much with them.

But it seems like you are using the *TI* ARM compiler, correct? If so then the recipe on the launchpad page should work for you.

There can be different reasons for not being able to 'see' the range:
eccRAM (RW) : origin=0x08400000 length=0x00080000 /* 512K of ECC */

1st: If the debugger returns some 'error' in a memory view window, then this may just be an issue of the debugger's memory map. For example CCS takes a memory map and will not create accesses to regions not explicitly listed in the memory map ... even if you happen to 'scroll' into that region while viewing memory. This is useful because some address ranges have side effects or can cause exceptions if read, and it prevents the debugger from creating these errors..

2nd: if you execute code on the CPU that tries to read from this address range, but you get a data abort, you need to check the settings of the memory protection unit. It needs to be configured to allow such a read.
Note that even if you haven't enabled the MPU there is a *default* memory map that it uses. [can be found in the CPU's reference manual].

Is the issue you're having related to either of the 2 above or is it something else ?

2) I am definitely seeing an Abort when the code attempts to read from the Level 2 RAM ECC address range.

Is the level 2 RAM ECC memory range (defined as 0x0840_0000 to 0x087F_FFFF) not valid in the default memory map in the MPU?
Is defining this range in the linker file sufficient to implement the Level 2 RAM ECC range in the MPU? Does this memory range need to be configured at every power-on in the MPU?

Laura,

It's valid in the CPU's 'default' memory map.   See

Or if there's a problem w. that link I'll paste a picture below.

Ok, but I *dont* see it in the HalCoGen default memory map under R5-MPU-PMU (second image)

So if you used HalCoGen and generated code with this default HalCoGen memory map, and enabled the MPU then an access to 0x0840_0000 would fall through to the catch all 'Region 1' which says it's not accessible, and you should get an abort.

Did you use HalCoGen?  If so then it's easy to confirm.   If not you can confirm your MPU settings at the time of the abort using the debugger to read out CP15 registers but this isn't the easiest thing to do...

The CPU documentation from ARM for the default memory map... when the MPU is disabled.  This shouldn't give an abort on 0x0840 0000

because it's part of that 1st 0x0000 0000 to 0x3FFF FFFF block.   However, I can't find any doc. saying whether this is 'privileged'.  I doubt it, but can't find it.  So only say 90% sure it's not this ...

Since the ecc isn't in the list,  you'd fall through to the 1st region (red arrow) which is marked as inaccessible in any mode.  So it'd generate an abort..
So I'm pretty sure you've got the MPU on but don't have a region assigned that allows access to the ECC...

Just enable one of the unused regions in the page below,  make it open up the ECC area, and regenerate / rebuild to fix the issue.

(if you are using HalCoGen... ;)

1) if L2RAM ECC is not defined in the Memory Protection Unit (MPU) (see #2) does that mean that Data ECC (RAM1 on page 69 of spnu540) is Disabled?

2) I did not use HalCoGen, and this code has gone through several iterations already so,

a) from DDIO460D_cortex_r5_r1p2_tfm.pdf page 4-42 and lauterbach I can see that ECC for B1TCM and B0TCM and ATCM are disabled

b) from DDIO460D_cortex_r5_r1p2_tfm.pdf page 4-46 and lauterbach I can see that BTCMECC and ATCMECC in Secondary Auxiliary Control Register are enabled.

c) bellow is what I can see of the Memory Protection Unit and it looks like ram in RBAR2 does not include L2RAM ECC at 0x08400000

Where RBAR0 is in T32/pertms570lc4xx.per at

tree "MPU regions"
group c15:0x0016++0x00
saveout c15:0x26 %l 0x0
line.long 0x00 "RBAR0,Region Base Address Register 0"

Hi Laura,

Thanks for posting this.  Looks like the LauterBach tool has a nice MPU visualization tool.

Laura Yindra1 said:

1) if L2RAM ECC is not defined in the Memory Protection Unit (MPU)

(see #2) does that mean that Data ECC (RAM1 on page 69 of spnu540) is Disabled?

No.  And in fact on this device I do not believe it is possible to disable the ECC check.

What it means if you do not have the region defined in the MPU is that a CPU read or write to address 0x084xx xxxx is going to cause an abort and be blocked.

But the ECC is still active, and writing to 0x0800 0000 (the actual L2SRAM) is going to cause the ECC to be updated in the RAM wrapper by 'logic' .. likewise reads from that region will cause ECC to be checked.

What it means not having the mapping in the MPU is that you can't 'directly' look at the ECC data w. the CPU ..

Regarding the TCM memories - there are no TCM memories on the device that you are using.   TCM memories are L1 memories directly connected to the CPU.  On your device, you only have L1 instruction and data cache.   All the flash and SRAM are cacheable and on L2 of the memory system.

On the RM4xx devices, it's the opposite,  all memories are TCM, no cache.   That works well up to about 200Mhz but above that we need cache for speed.

-Anthony

Is there a way to test the SRAM ECC with out enabling the 0x8400000 section of RAM and without configuring the ESM?

right now I'm always entering s_vim_init[1] which is esmHighInterrupt and entering esmGroup2Notification because (ESM->IOFFHR - 1U) is less than 64 or between 128 and 160.

Laura,

So by 'enabling the 0x8400 000 section of RAM' I am assuming you mean 'adding an MPU region that enables the CPU to read and write this memory directly'.

Also I assume you're not talking about the PBIST test of the ECC RAM array itself but rather the SECDED detection and notification mechanism.

For the latter - why wouldn't you want to make sure that the error is detected and actually propogates to the ESM and generates an ESM error?

does the TMS570lc4x ever correct a 1 bit L2RAM ECC error without notifying the ESM or EPC?

does the TMS570lc4x ever correct a 2 bit L2RAM ECC error without notifying the ESM or EPC?

Laura Yindra1 said:

does the TMS570lc4x ever correct a 1 bit L2RAM ECC error without notifying the ESM or EPC?

L2RAMW Module Control Register (RAMCTRL) gives you some control as to whether or not certain single bit errors cause an ESM notification.

Laura Yindra1 said:

does the TMS570lc4x ever correct a 2 bit L2RAM ECC error without notifying the ESM or EPC?

The ECC logic is SECDED  (single bit error correction, double bit error detection)..  So double bit errors are not corrected only detected.

Regarding EPC this isn't clear in the TRM and will need to be researched.