TMS570LC4357: Injecting ESM group 3 error(s)?

Hi Magnus,

Started to look into your issue and i will provide an update very soon.

--

Thanks & regards,
Jagadish.

Hi Magnus,

Did you get a chance to look into the definition of the function "SL_SelfTest_SRAM" in SafeTI Diagnostic Library

--

Thanks & regards,
Jagadish.

Hi,

Yes, the LC4357 is an R5 device, so that test is not available. I believe that in these devices, the ECC functionality cannot be fully disabled in the way that this type of test requires.

Other group 3 faults than those I listed would be fine as well. The main goal is to verify our error handling.

Regards,

Magnus

Hi Magnus,

Magnus Aronsson said:

the ECC functionality cannot be fully disabled in the way that this type of test requires.

Yes, you are correct.

I don't think we can generate ESM3.3 and 3.14 but i found few threads to generate ESM 3.15

Please have a look on below threads,

(+) TMS570LC4357: RAM13 Triggers EMS 3.15 as well as 2.17 and data abort - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) TMS570LC4357-EP: Regarding Address Parity Override of L2RAMW - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) TMS570LC4357: Diagnostics of L2RAMW Address and Control bus Parity by inverting parity scheme - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

--

Thanks & regards,
Jagadish.

Thank you, this is very helpful.

As noted in those threads, this test also triggers ESM 2.7. This leads to ESM High interrupt occuring, but I am not seeing a Data Abort event - why could this be? In one of the others threads they mention getting a data abort event and, as I understand it, ESM 3.x should always lead to CPU aborts.

Regards

Hi Magnus,

I don't think Data Abort will generate for all ESM3.x errors.,

The Data Abort exception is generated in Hercules microcontrollers when an attempt is made to access an invalid memory location. This can happen due to a number of reasons, such as:

1. A program attempting to access a read-only memory location.
2. A program attempting to access an uninitialized memory location.
3. A program attempting to access a memory location that does not exist.
4. A program attempting to access a memory location that is not accessible due to security restrictions.

When any of these scenarios occur, the microcontroller will generate a Data Abort exception, which is a type of exception that signals a problem with memory access.

May be on the first thread i shared the customer may also try to access some invalid memory to create ESM errors.

--

Thanks & regards,
Jagadish.

Ok, but it was my understanding that group 3 errors should always generate CPU aborts. Since they do not trigger the interrupts, how else could they be handled by software? <I did try to confirm this in this linked thread recently.>

Could it be affected by the diagnostic mode being activated while performing the RAM13 diagnostic test?

I would be interested in forcing some other group 3 error as well.

Regards,

Magnus

Hi Magnus,

Can you please forward your code, i will debug it at my end once?

--

Thanks & regards,
Jagadish.

Hi,

Closing the thread because of not hearing back from so long.

--

Thanks & regards,
Jagadish.

Hi,

Sorry, I got busy, and then the thread was already closed last I tried to follow up?

Anyway, i would still like to inject any Group 3 error and verify that it causes som type of CPU abort/exception.

Unfortunately I cannot send my code, but I will post the code I used to successfully cause a group 3 error as mentioned above, which did not cause any CPU abort, only ESM interrupt from the group 2 error.