Please explain what is "FMC - uncorrectable error: bus1 and bus2 interfaces" in ESM Group3 Channel 7

Hello Pashan,

I can provide some partial details.  Bus1 is the TCM access port to the flash wrapper.  Bus2 is the separate FEE interface.  You can distinguish based on the address of the target transaction whether it was a Bus1 or Bus2 access.

Our flash wrapper designers will need to provide more clarification.

Best Regards,

Karl

Hello Pashan,

  The flash wrapper has two interfaces, the bus1 and bus2 as you already know. Bus1 is connected to the TCM I/F of the CPU while the Bus2 is connected to the AXI I/F of the CPU. Accessing flash's OTP, ECC and EEPROM regions is done through the Bus2 I/F which means the access transactions are generated from the CPU's AXI I/F. The idea is to keep timing critical and latency critical accesses in bus1 while transactions go through bus2 can afford more latency.

regards,

Charles

Hello Charles,

I am unable to attach PICTURE from DATASHEET within this mail.

Instead, I am attaching the PICTURE from DATASHEET of TMS570LS3137 device for easy undersdtanding.

According to the DATASHEET, ESM Gorup 3 Channel 7 will generate ESM ERROR PIN LOW under following two conditions:

1> Bus 1 Access Error -- which is ATCM Flash DATA Access by CPU  --  CPU ABORT Interrupt Vector [ARM defined Vector Table] will be called as well as ESM ERROR PIN will be LOW

2> Bus 2 Access Errror -- which is EEPROM or OTP or ECC error  -- No CPU ABORT Interrupt Vector will be called but ESM ERROR Pin will be LOW

Are all the above statements correct for TMS570LS3137 device?

For Case 1> I am expecting to see FEDACSTATUS Register Bit 8 as HIGH  -- Is that correct?

For Case 2> which bit of FEDACSTATUS Register will be set?

Please answer below every question individually for my easy understanding.

Thank you.

Regards

Pashan

Hi Pashan,

  For #1, your understanding is correct that an uncorrectable error in the event of double bit ECC error will cause an abort to the CPU and also asserting nERROR pin low. Bit8 will indicate this type of uncorrectable errors on bus1.

 For #2, one correction to your understanding is that an uncorrectable error due to an access to EEPROM is not mapped to Group 3, channel 7. Uncorrectable error due to EEPROM access is mapped to Group1, channel 36. See the same table. For uncorrectable on bus2 due to ECC error you can find out from bit 17 of the FEDACSTATUS register. For uncorrectable error due to EEPROM access, the error flag will be captured in bit8 of EE_STATUS register which has the offset address of 0x31C in the flash wrapper.

regards,

Charles

Hello Charles,

Is there any TEST Code available for TMS570 HDK with which I can see that Bit 17 of FEDACSTATUS Register is being set due to Bus 2 Error and no ABORT taking place?

Please help me with some test code.

Thank you.

Regards

Pashan

Hello Pashan,

  The best way to cause a bus2 uncorrectable is during compile time by using nowECC to generate intentional double bit fault in the ECC code as part of the object file. Once the code is flashed you will make your code to read from the known location that has the intentional double bit ECC fault. The uncorrectable error will then be captured in bit17 for bus2. Please note that you will need to insert intentional uncorrectable ECC fault at an OTP location because OTP region is accessed via bus2. Please refer to section 2.2.19 in the nowECC userguide.

http://www.ti.com/lit/htm/spnu491 

 regards,

Charles

Hello Charles,

In your first mail you said the following :

"Accessing flash's OTP, ECC and EEPROM regions is done through the Bus2 I/F which means the access transactions are generated from the CPU's AXI I/F. The idea is to keep timing critical and latency critical accesses in bus1 while transactions go through bus2 can afford more latency."

Which means creating ECC Area of Flash DATA Space  [0xF040 0000 to 0xF040 1FFF] Address Ranges of TMS570LS3137 device will also create Bus 2 fault.

Is that not correct?

Thank you.

Regards

Pashan

Hello Pashan,

You are right that the ECC code is also memory mapped at address starting 0xF040_0000. You are also right that CPU can access to the ECC region via bus2. It should work if you corrupt two bits in the ECC code corresponding to the normal flash program area. For example, corrupt two bits in the ECC code corresponding to location 0x0. When you read from the ECC code at 0xF040_0000 you will detect an uncorrectable error and set bit17.

regards,

Charles

Hello Charles,

1> Do I have to enable/set Bit 4 of "c9, Performance Monitor Control Register" in order to see FEDACSTATUS Register Bus 2 [Bit 17] error?  -- Bit X of ARM TRM

2> Do I have to enable/set Bit 25 of "c1, Auxiliary Control Register" in order to see FEDACSTATUS Register Bus 2 [Bit 17] error? -- Bit ATCMPCEN of ARM TRM

Thanmk you.

Regards

Pashan

Hello Pashan,

   These two registers (the X bit in Performance Monitor control register and ATCMPCEN bit of the Auxiliary control register) you mentioned need to be set for bus1 error generation to the ESM but not for bus2. Setting the X bit will enable the exporting of event bus from the CPU core. In this case, the correctable or uncorrectable error event detected by the CPU will be exported to the flash wrapper. When the flash wrapper captures these error events it will then send to the ESM.

   Flash wrapper has a local SECDED ECC logic for bus2 accesses. The reason is that the Cortex-R4 does not perform ECC check for AXI transactions. If flash wrapper detects correctable or uncorrectable error on bus2, it will signal to the ESM directly.   

regards,

Charles

Hello Charles,

For ECC Check, I thought Cortex-R4 accesses 64 Bit of Flash DATA SPACE and calculates 8-bit ECC value. Then this Calculated 8-bit ECC value is compared against Stored 8-bit ECC [0xF040 0000 ---]. If mismatch, then ESM as well as FEDACSTATUS error are signaled.

So, in your 2nd last mail, you said if I corrupt ECC cell contents, then I will get FEDACSTATUS Bit 17 error.

I am confused, because ECC Error is miscompare with Calculated ECC with Stored ECC. So, in theory, I can also corrupt Flash DATA Space without changing ECC cell contents which effectively changes Calculated ECC and hence ECC Error will be activated.

Let me know if my understanding is correct.

Please elaborate more about how to create Bit 17 of FEDACSTATUS fault.

So, I am writing some code to activate Bit 17 Fault in FEDACSTATUS, which is runninvg in Cortex-R4. Hence, how does that code performs Bus 2 access? Does it mean, whenever Cortex-R4 directly accesses 0xF040_0000 --- address space it goes over AXI Bus [Bus 2] access?

Thank you.

Regards

Pashan

Hello Pashan,

 "For ECC Check, I thought Cortex-R4 accesses 64 Bit of Flash DATA SPACE and calculates 8-bit ECC value. Then this Calculated 8-bit ECC value is compared against Stored 8-bit ECC [0xF040 0000 ---]. If mismatch, then ESM as well as FEDACSTATUS error are signaled."

Let me clarify your above statement. Please note that when you access the Flash DATA SPACE you are using the bus1. So if there is an uncorrectable ECC error, you will see the bit8 getting set, not bit17.

I am confused, because ECC Error is miscompare with Calculated ECC with Stored ECC. So, in theory, I can also corrupt Flash DATA Space without changing ECC cell contents which effectively changes Calculated ECC and hence ECC Error will be activated.

Your statement here is correct. You can either corrupt 2 bits in the Flash DATA SPACE or corrupt 2 bits in the ECC check code. Either way will be detected as a double bit ECC error. As I have also mentioned that the ECC region (this is the memory map for the stored ECC checksum code) is accessed via the bus2 which is connected to CPU's AXI I/F. In order to generate an uncorrectable error which results in setting the bit17, you will need to create a transaction to the bus2. This means that you will need to read from the ECC region, not from the normal Flash DATA SPACE because that read transation will use bus1.

So, I am writing some code to activate Bit 17 Fault in FEDACSTATUS, which is runninvg in Cortex-R4. Hence, how does that code performs Bus 2 access? Does it mean, whenever Cortex-R4 directly accesses 0xF040_0000 --- address space it goes over AXI Bus [Bus 2] access?

Your understanding here is correct. If you access location 0xF040_0000 it will become an AXI Bus 2 access.

regards,

Charles

Hello Charles,

That means when Cortex-R4 core accesses [READ] ECC Space [0xF040_0000 --- ], then internally Flash Wrapper checks the Stored ECC Value with 64-Bit Corresponding Flash DATA Space[0x0000 --- ]  Calculated ECC value and creates Bit 17 Error wihin FEDACSTATUS in case of mismatch.

Under the above mentioned condition, Cortex-R4 ECC Check Logic is not used at all.

Are both of the above statements correct?

Thank you.

Regards

Pashan