TMS570LC4357: Problems when executing Diagnostics RAM16 and RAM17 consecutively during Power On

Max Wittekind

Hi experts,

We encountered a problem when running Diagnostic RAM16 (Ram ECC Profiler Test) and RAM17 (RAM Redundant Addressdecode) in Power On consecutively.

The first problem we encountered after adding RAM16 was that the Efuse Autoload test started failing. After doing a reset or a Power On RAM17 sometimes failed, although beeing executed before RAM16.
Taking RAM16 out of the test sequence and doing a Power On reset always fixed the problem.
The easiest solution that we got working is adding a wait function after RAM17 of about 5000 - 10000 Cycles.

the following steps are part of the RAM16 diagnostic:

- Write 0x0 to RAM with ECC active
- disable ECC and Enable ECC_WR_EN
- write 0x5151515151515151 into ECC to inject 1-Bit error (64-Bit write)
- activate ECC
- read access ram (64-bit read)
- check if ESM 1.4 is set
- check and clean up CAM
- korrekt ECC
- reset ESM and nERROR

What could be the reason for this problem?

Thank you and best regards,
Max

_____

edit: the procedure decribed is that of RAM16 not Ram17

over 3 years ago

0 jagadish gundavarapu over 3 years ago

TI__Guru* 75096 points

Hi Max,

We started working on your issue and we will get back to you soon.

Thanks & Regards,

Jagadish.

0 QJ Wang over 3 years ago in reply to jagadish gundavarapu

TI__Guru**** 199386 points

Hi Max,

The device provides a mechanism to test the redundant address decoder logic and compare logic. It is enabled by writing 0xA to RAMTEST register and the test is performed by writing 1 to trigger bit of RAMTEST register.

0 Max Wittekind over 3 years ago in reply to QJ Wang

Expert 1885 points

Hi QJ,

I found a mistake in my previous post and corrected it.

After checking our code again we did find an erorr in our RAM16 diagnostic which seems to allow us to get rid of some of the wait functions.
Now it looks like we only need to wait only 2000 -5000 Cycles before testing the redundant address decoder.

When implementing the test, we used the "void _SL_SelfTest_SRAM_RAD (sl_l2ramwBASE_t * ramBase, SL_SelfTest_Result * rad_stResult)" (SafeTi Lib 2.4.0).

The Technical reference manual mention the following in section 8.2.6:

Is it possible that waiting a few cycle before running the test, ensures, that the memory banks are not busy and the test is executed immediatly?

Thank you and best regards,
Max

0 QJ Wang over 3 years ago in reply to Max Wittekind

TI__Guru**** 199386 points

Hi Max,

I am not sure if using DSB is good way for you. The instructions after DSB instruction are not executed until all memory accesses before DSB are completed.

0 Max Wittekind over 3 years ago in reply to QJ Wang

Expert 1885 points

Hi QJ,

We are currently not using DSB. We just wait by using a for loop and __asm__ (" nop"). Using the DSB instruction did not seem to work.

0 QJ Wang over 3 years ago in reply to Max Wittekind

TI__Guru**** 199386 points

The trigger bit is auto clear after the test. You can use a while() to wait until TRIGGER is cleared.

0 Max Wittekind over 3 years ago in reply to QJ Wang

Expert 1885 points

Hi QJ,

Waiting for the TRIGGER bit did not change anything. But running the Test before running any other test on power-on works without any wait time.
Running the test after for example PMM5 and PMM6 Diagnostic requires a delay, otherwise the test or another test after that fails.

Any Idea what could be the problem with this?

Thank you and best regards,
Max

0 QJ Wang over 3 years ago in reply to Max Wittekind

TI__Guru**** 199386 points

Hi Max,

I just performed a test using SDL, and it passes. I did PSCON selftest before SRAM RAD test without any wait time:

1. PSCON self test

2. SRAM Selftest (RAD)

Arm-based microcontrollers

Arm-based microcontrollers forum

TMS570LC4357: Problems when executing Diagnostics RAM16 and RAM17 consecutively during Power On