Safety diagnostic library loops on SL_SelfTest_Flash function

Davide,

If the issue is that the test doesn't run, because it's checking the nERROR pin or other ESM status before executing the test and returning a fail because prior code didn't clear the flag - then this is a known issue with the example.
If it's something else please provide more detail or your project...

Anthony,

I added in the module 'app_main_NoOS.c' at line 364 the function SL_SelfTest_Flash but the test gets stuck in a loop. Following line 364:

retVal = SL_SelfTest_Flash (FLASH_ADDRESS_PARITY_SELF_TEST, TRUE, &testResult); //db

 

Could you tell me where is the problem in the example? Where is the bug in the demo application?

I attached my 'app_main_NoOS.c' modified.

2350.app_main_NoOS.c

Thank you & Best Regards

Davide

 

 

 

Hi Davide,

Ok I think I can reproduce. And by writing 0x10 to STAT2 through the debugger I can kick it out of this error loop.
I think reading the offset normally clears the flag so I'll need to figure out why this isn't happening.

EDIT:  The ESM group 2 channel 4 flag is actually getting cleared on the read of the offset register.

But it's getting triggered again inside the esmGroup2Handler function on a branch that makes up the 'break;' in the case statement line 311

of sl_esm.c.    This is a branch from address 0x0B120 to 0xB208.  

So need to find out why this is retriggering;  but the behavior makes sense if every time the handler is run it creates another event for itself,  it would loop forever.

Might be some problem in how the test is initiated...

Here is something a bit interesting - it's a trace capture that I got with the PROTRACE emulator - showing where the error interrupt is triggered.  It actually seems to be triggered as soon as this occurs: 

sl_flashWREG->FPAROVR |= F021F_FPAROVR_ADD_INV_PAR;

That is a bit of a guess because the assertion of the ESM error isn't visible in the trace, just the interrupt service routine start.  The latency is about 12 cycles through the VIM but there is probably some additional cycles for ESM... this looks like the likely candidate.

Anyway if you read the TRM it says that a data read from the special 'ecc error' location in the flash (step 5) would trigger the error and then after that you disable the test mode.   This particular diagnostic mode 7 is used for the address parity *and* the ECC tests.  But I think it may behave differently for the address parity. 
It looks like it's not a 'one shot' triggered by a particular address but constant.   Then just executing(?) from flash again during the interrupt service routine is probably triggering the issue again,  and you never get back to the main 'app_main_NoOS.c' level where the code subsequently would have executed steps 9, 10 ... 

I'm attaching the whole trace file as well: 

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/312/5226.SL_5F00_TMS570LS3137_5F00_NoOS.tdf

You should be able to open this in CCS even if you don't have a PROTRACE by using the menu Tools->Hardware Trace Analyzer->Open Trace File and navigating to the .tdf file. 

You can see by scrolling through this file that it never does get back to the main() function - it loops over and over:

sl_esm_high_intr_handler

esmGroup2Handler

SL_FLAG_GET

esmGroup2Handler

ESM_ApplicationCallback

esm_Group2Handler

sl_esm_high_intr_handler

repeat... 

See how above as soon as the FIQ exits with SUBS PC, R14, #4 the next instruction is right back into FIQ -- this happens because the FIQ is still pending. 

(even though FIQ is NMI, inside the FIQ handler FIQs are masked until the CPU re-enables them .. which normally it shouldn't... so the pending FIQ is delayed until the current FIQ ISR exits in which case FIQs are automatically enabled again. )

What I need to understand now is whether testing the address parity is different than testing the other mode 7 diagnostics. 

The ECC diagnostics on the data portion have a 'trigger' bit in the FDIAGCTRL register and they are supposed to be 'one-shot'. 

So that would prevent a continual loop of triggering injected the error over and over. 

It may be that we don't have this one-shot setup properly or that it just doesn't work for the address parity error because of the location in which the error is injected.   

Former would mean a fix to the safety library. 

Latter would mean you would probably need to relocate this test to RAM to execute - so that you can avoid uncontrolled error generation until the code (executing from RAM) can turn the diagnostic mode off before branching back to flash. 

Still more research to do on the fix, but it does seem clearer what the problem is just not the ultimate cause. 

Best Regards,
Anthony

Davide,

Turns out this is a known issue w. the safety library (I need to check release notes).
It's supposed to be addressed by an upcoming release in middle of April.
If possible I would suggest commenting out this function call until the update is available.

Best Regards,
Anthony

Anthony,
thank you for the help, the work you have done is very detailed. As you suggested, we will wait for new realease.
Best Regards,
Davide