Hello,
As requested here I'll open new topic: e2e.ti.com/.../2232968
That test looks to generate 1bit ram errors to both banks with 1 unaligned access, after the test SR1 has value 0x1400 0000 - that looks correct. But those ESM errors are not acked nor checked so bits are left active in the ESM when test is exited also return value is not set and registers content not restored. In case this test is run in the start up routines (recommended phase 29 where testing the RAM is mentioned) the SR bits will be cleared later by ESM init (in recommended phase 42).
Based on my observation for this live clock test (compared to "any other" group1 test):
- Test return value (sram_stResult) is not touched, returns what user gives (this is not a fault inject test based on the test name or functionality)
- ISR & nERROR action is not back upped and turned OFF in the beginning
- ESM register status is not verified after the fault(s) has been generated
- ISR & nERROR action is not returned
Based on my observation for this live clock test (compared to "other SRAM" tests):
- RAMTHRESHOLD value is back upped BUT not restored
- RAMCTRL value is not back upped nor restored
- Uses "application" RAM without IRQ protection ( tp = (volatile uint64 *)0x08000004u; /*start address of unaligned access*/ ) should it use sramEccTestBuff[0] & sramEccTestBuff[1] and take ½ point from there "tp = (uint64*)((uint8*)&sramEccTestBuff[0] + 4)" like those other tests do to ensure that application does not operate in same RAM range???
- RAMOCCUR is not written to 0 like in other tests in the beginning
Test pattern what happens if ramoccur != 0 for live clock test --> no ESM errors reported like TRM says
sl_tcram1REG->RAMOCCUR = 5; // emulate that errors has been already happened before this test
sl_tcram2REG->RAMOCCUR = 5; // emulate that errors has been already happened before this test
/* set threshold to 1 */
sl_tcram1REG->RAMTHRESHOLD = 0x1u;
sl_tcram2REG->RAMTHRESHOLD = 0x1u;
Test could make runnable just by adding those "basic" routines to the beginning & end of the test which are in other tests.
After that the currently used RAM address 0x08000004 is the only one rising questions why it does not use the same test area as other 1 bit error tests (basically it should not matter since if application simultaneously access the area, the error is corrected. But if there is another bit flip due to disturbance say in 08000000-08000003 area at same time and application reads from RAM start then this would cause uncorrectable error (probability for this is of course small)...
Which unique identifier belongs to this test: RAM13 / RAM12? Is this test needed to full fill the unique identifier where it belongs to or is it enough to run similar "SRAM_ECC_ERROR_FORCING_1BIT" test?
Also would like to ask (to improve own understanding): does this test something different than SRAM_ECC_ERROR_FORCING_1BIT when it generates errors individually to both banks and this live clock test makes the error with just 1 unaligned access which goes simultaneously to both banks?
