TMS570LC4357: FLASH : Access Time-out error

Hello,

1. disable the cache

2. disable the prefetch for PORTA and PORTB

3. write 0x1 to acc threshold register

4. read flash

You will get the ACCTOUT error and esm error (group 3):

It worked but it also raise the ESM group 2.16 channel bit whereas I cleared the ESM before the test.
I am not sure why this happend and according to the documentation it is marked as "reserved".
Did you notice something similar ? Do you have any idea why this bit is raised.

Thanks again for your help.

The simple fact that we can trigger an exception which is documented as reserved is not normal. ESM group 2.16 should be documented in the Datasheet Table 6-45. ESM Channel Assignments.

Regards

I run more tests and noticed that flag ESM group 2.16 is only raise when PMCR bit X is equal to 1.
Do you have the same error with this bit enabled ?
Regards

Which register? I don't what does PMCR stand for.

It stands for Performance Monitor Control.

The bit X is necessary in order to trig ECC error.

Hi,

Could you ask design team? I know ESM 21.6 does not exist in the documentation, but we managed to get it raised. While we try to send you a reproducer, please ask them so that we know if yes or no the ESM module has an input connected to its 2.16 input. What I expect is that among the 55 bits of the EVNTBUSm bus being outputted by the core, some are not routed to ESM 2.3 and 3.9, but to other channels such as 2.16. Please ask.

Thanks.
Étienne

Hello Étienne,

I will check. As far as I know, the reserved channel is not tied to any logic input.

Hello Étienne,

I was told that the reserved ESM channels are tied off (logic ground). Could you please try your code on another silicon? I could not reproduce the problem. After my flash time-out test, the ESM group2 channel 16 is always 0.

Hi,

Just to prove our words, here is a screenshot showing the state of ESM.ESMSR2 after the steps. ESM 2.16 is really set... :)

Hi,

Here is more information. We have enabled the PMU counter on event 0x62 "Processor livelock because of hard errors or exception at exception vector." (EVNTBUSm bit position [35]) just before getting the Flash access time-out exception. To get the exception, we set L2FMC ACC_THRESHOLD to 0x1 and then we run to execute and instruction in Flash. We then hit the Prefetch Abort handler (this is expected). Then, we reverted back ACC_THRESHOLD to 0x5FF via the debugger (to allow further code execution...). With all that, we noticed that the PMU had counted 2 events! We also restarted the same steps, but with another PMU event just to make sure our measurement was good (event 0x71 "All fatal bus faults") and we got a PMU counter to 0, as expected.

It is logic to see 0x62 counter increment since the L2FMC corruption we had introduced produces a Prefetch Abort each time the Flash is accessed, including when attempting to execute the Prefetch Abort handler itself ... which is located in Flash :) So we get into an infinite loop of Pretech Abort exceptions, exactly what describes PMU event type 0x62.

So this means the ESM sets 2.16 when it receives EVNTBUSm bit position [35] from core. Doesn't TI engineering team confirm there is that connection in the design? If not, then to what is connected EVNTBUSm[35]?

Note: PMCR[X] needs to be set to 1 for the PMU event to be exported to the ESM.

Thanks.

Also I noticed the same behaviour with the wait states for flash read at 3 for my test. (before it was at 2)

Hello Étienne,

Have you done the test on a separate silicon? I just did the test with smaller wait states on another LC43x HDK (RevA silicon) which generates ESM 3.13 error, and I could not produce the error on ESM 2.16. It might be caused by a failure part.

We tried on different silicon and same results happens.
When you perform your tests, did you set the PMCR bit X to 1 ?

We performed a different test which is another mean to get the ESM 2.16:
- In you handlers source code, change the undefined handler instruction to :"udf #0". Recompile and download.
- Reset the CPU, set PMCR bit X to 1, set the PC to 0x4 (Undefined handler).
- Look at ESM ESR registers (should all be zero)
- Then do a step in or run and stop.
- ESM 2.16 is now set! (ESMSR2[16]=1)

Hi

Do you mean PMNC register (Performance MoNitor Control register)? Bit 4 is used to enable the export of events to the event bus. The bit 4 of PMNC is enabled in my startup code:
_coreDisableEventBusExport_
mrc p15, #0x00, r0, c9, c12, #0x00
bic r0, r0, #0x10
mcr p15, #0x00, r0, c9, c12, #0x00
bx lr

The following is the code in my main()
//do Flash diagnostic test

/*clear ESM error*/
esmREG->SR1[1] = 0xFFFFFFFF; //clear ESM group 2
esmREG->SR1[2] = 0xFFFFFFFF; //clear ESM group 3
esmREG->EKR = 0xA;
esmREG->EKR = 0x0; //clear the nEROR pin

#if 1 //doing flash ACCTIME out test
//disable cache
_cacheDisable_();

//disable flash prefetch
flashWREG->FRDCNTL = 0x00000000U
| (uint32)((uint32)3U << 8U)
| 0U; //0x3 to enable the prefetch
flashWREG->ACC_THRESHOLD = 0x1;

for(i=0; i<100; i++){
flashData = *(unsigned int *)(0x00000004 + i*4);
}

//check the ACCTOUT
error = (flashWREG->FEDAC_PASTATUS >> 15);
error1 = (flashWREG->FEDAC_PBSTATUS >> 15);

#endif

while(1);

Do you think my code is not able to trigger ESM 2.16?

Hi,

Yes, that's the one (we're using the official register names from ARM Cortex-R5 TRM, that why the difference).

However, I think the code you show DISABLES the PMCR.X bit...! The bic instruction stands for "bitwise clear" and allows to selectively clear some bits.

Also, for your code to generate ESM 2.16, you need Prefetch Abort handler to be in flash (it will). Since it will get called, I don't understand the purpose of the "check the ACCTOUT" line and while(1) line: they will never be reached.

After correcting that, if you still do not get ESM 2.16 please try the Undefined trick we suggested (it is a simpler reproducer in my opinion).

Thanks,
Etienne

Hi,

We need to get that mystery clarified. Please try the Undefined trick I proposed earlier which is generating an Undefined exception at the Undefined exception vector (i.e. at 0x0000_0004 in Flash, not in a function later called by the vector), while having PMCR.X=1. You can do this by corrupting the instruction found at 0x0000_0004. See my previous post. This should raise ESM 2.16.

Thanks,
Étienne

QJ Wang, were you able to reproduce the issue with the Undefined exception?
Étienne

Hi Étienne,

Sorry, I haven't got chance to do test with your approach. We will check the RTL code.

Hi Étienne,

My apologies. I haven't got chance to do test and will do it as soon as I can.

Hi,

I think we don't understand each other. Let's forget about Flash parity error prefetch. I am proposing another way. So please no longer change or look to registers in the FlashWrapper.

Rather than simulating a parity error in the Flash, I am now proposing to generate an exception at the exception vector (infinite loop of exceptions). Please follow the steps I had described on Feb 20, 2019:

We performed a different test which is another mean to get the ESM 2.16:
- In you exception vector/handlers source code (crt0.s?), change the undefined handler instruction to :"udf #0". Recompile and download. Example of code:

EXCEPTIONS_VECTOR:
ldr pc, RESET_ADDR ; Reset
udf #0 ; Undefined exception -> will generate an infinite loop of undefined exceptions
ldr pc, SVC_HANDLER ; Software interrupt (SWI/SVC) exception
ldr pc, PREFETCH_HANDLER ; Prefetch abort exception
ldr pc, ABORT_DATA_HANDLER ; Data abort exception
dcd 0 ; RESERVED
ldr pc, RESET_ADDR ; IRQ exception
ldr pc, [pc,#-0x1B0] ; FIQ exception

- Reset the CPU, set PMCR bit X to 1, set the PC to 0x4 (address of Undefined handler).
- Look at ESM ESR registers (should all be zero)
- Then do a step in or run and stop.
- ESM 2.16 is now set! (ESMSR2[16]=1)

I know this sounds stupid (doing an undefined exception on purpose), but it's only to demonstrate that ESM 2.16 really does exists...

Thanks.
Étienne

Great!

At the same time, is there other ESM Group 1/2/3 sources which exist in the design but which are not documented?

Étienne

Thanks Sunil checking the RTL for ESM2.16

Could you please double check the other reserved ESM bits?

As a side note, I think I found why that was missing from the documentation: DEVICE#46 errata of Silicon A mentioned that ESM was not connected to PMU event 0x62 (livelock). That was corrected on Silicon Rev. B, but I guess documentation was not updated accordingly... :)