RM48L952: SafeTI & TRM: ECC DIAGMODE = 7

Hello,

“True DMA module” means the DMA module on the device. Before call the function for ECC data correction diagnostic mode 7, the DMA has to be turned off.

There are bugs in the sequence for diagnostic mode 7:

It should set the DIAG_MODE and the DIAG_EN_KEY first before setting up the other registers to block the other registers from causing a false error. The sequence (in 5.6.2) is correct. 

 The #2 in mode 7 sequence should be:

2.  Put 0101b into BUS_PAR_DIS and 101b into PAR_OVR_KEY fields (00005Axxh) of the FPAR_OVR register (0x7C).

The DIAG_TRIG is needed (diag_trig=1) after all registers are loaded with intended values. The DIAG_TRIG serves to validate the diagnostic result. Only when DIAG_TRIG is set to  and a failing result in the diagnostic logic will update the corresponding status flag and the position register.

Regards,

QJ

Hello,

Does the DMA module needs to be turned off in case it does not read anything from the flash (ours is moving data only from peripherals to CPU RAM or vice versa so no flash access)? If yes, then this critical check is missing from entry conditions from flash & fee tests in SafeTI. If no, then SafeTI user manual misses that quite critical detail from notes and DMA shall not operate flash...

In case the DMA needs to be turned off without exceptions (which is most likely either impossible or at least really complex task to suspend application receiving/sending the data from/to outside world) do you need to run the FLASH (or FEE) test during runtime? For STC (and PBIST) is said in multiple locations in 'public e2e' that usually there is no need to perform them ever periodically and for these tests there is also unique identifier with A/B selections), is this somehow application depended or something? Based on quick evaluation in FMEDA excel only FLA5B & FLA7 has impact to FIT, all other FLA tests can be 0 and FIT (&other diagnostics values) stays in same value some basically any of the flash-related SafeTI tests does not have any effect to FIT. Is this "do you need to run test X" or "FIT" discussion going to 'private e2e scope'?

What is the safety related point of running these tests (at all, not even in boot) in case those has not any impact to FIT?

I run those tests also once in "recommended" CPU start-up phase number 30 concerning flash tests (http://www.ti.com/lit/an/spna106d/spna106d.pdf but with FIQ or IRQ disabled it is not same, since then you cannot be sure that FIQ or IRQ is signaled correctly in real situation, FIQ concers only 1 test in FLASH and IRQ another one, others generates data_abort which goes through also in start phase. I also think that fault injection tests should be run at least once with FIQ&IRQ enabled in order to be sure that real faults are really catched in application level also.

Currently I have all FEE & FLASH tests running periodically (and DMA run's also continuously but does not operate flash, it just moves data from ram to ram in forever continuous loop) without any known side effect/issues to our application after some modification of SafeTI code (https://e2e.ti.com/support/microcontrollers/hercules/f/312/t/602739. Now based on this discussion I am starting to having feeling that the work what I have been doing with these particular tests (flash&fee) may be at least partly if not completely useless since there is no actual effect to FIT, DMA should be turned off (which I doubt that we could do in runtime which that tests should be dropped from excel). Of course moving these test to be performed once before DMA is started but after FIQ/IRQ enabled is doable quite easily in case there is a need to run them at least once with FIQ&IRQ enabled but is there any need even for that since no change in FIT?

Based on your comments there are then something wrong in the FLASH_ADDRESS_PARITY_SELF_TEST or somewhere else (my understanding perhaps?) since it does not set that DIAG_TRIG bit at all. I also understood from TRM that DIAG TRIG (or whole flash diagnostics concept) is one shot but this FLASH_ADDRESS_PARITY_SELF_TEST (and it's fault injection version) keeps generating group2 ESM error unless FPAR_OVR register is not disabled in sl_esm.c FIQ handler and there is 0x5400 write for that 'normal' test (in case tests fault inject version calls user esm_callback before 0x5400 is written then SR[1] has again bit up and in that case new FIQ request is set so the code ends up in FIQ-loop. Of course FIQ loop could be also avoided by writing that same 0x5400 and acking the re-risen SR[1] in application callback but since this is one shot diagnostics test I think that application level shouldn't need to do that it should be enough to check that SSR2 has bit up (for normal test SafeTI does not check that SSR2 acticity, it only checks that ADD_PAR_ERR is active, other tests checks also SSR2 register content)), that should not happen in case this diagnostics it is "one shot" or I just miss/haven't noticed some small but really important detail from somewhere.

Maybe some of this discussion should be under those 2 threads so feel free answer into other threads in case you feel that answers is better there...

Just noticed that this DMA concerns only diag mode 7, not other diag modes, so FEE is out of scope and FLASH_ECC_ADDR_TAG_REG_MODE flash tests what comes to DMA requirement. So it is at least ok to run FEE  and that 1 flash tests periodically from DMA point of view.