About the difference of Livelock function.

Hi Arriy,

  There is only one hard error cache inside the CPU. This hard error cache is used for both the Flash (sitting on the ATCM interface) and the SRAM (sitting on the BTCM interface). They are separately mentioned in the safety manual but in reality there is only one hard error cache that is used.

1) The Cortex-R4 processor attempts to correct 1-bit errors in the TCM by writing the corrected data back to the TCM and retrying the access. If a 1-bit error is due to a hard fault, then doing this will not change the data read from the TCM, and when the access is retried, the same error will be detected again and the processor will livelock, forever detecting the error and retrying and not making any progress.

The purpose of the hard error cache is to prevent CPU from reading the SRAM or flash which have permanent single bit error. Let's say there is a defect in one of the memory cells. If you read from it the CPU will detect it as a single bit ECC error. What the CPU will try to do is to save the corrected data to the hard error cache and also write back the corrected to the SRAM or flash and then retry. Next time if the CPU reads from the same error address then it simply read from the cache instead of reading from the SRAM or flash since there is a match in the address. You can use the RAMTHRESHOLD register to setup the single bit threshold occurrences. Likewise, the FEDACCTRL2 register for flash to setup the occurrences threshold.

2) There is no difference in behavior when the livelock happens to either flash or SRAM.

Hello,Charles.
Thank you for your reply.

I want to implement fault Injection test of the two safety mechanism.
If a fault insertion test is carried out and a live lock occurs, is it that you have performed both(Flash/SRAM) fault insertion tests ?

Please let me know if you know different Livelock generation methods in FLA and SRAM.

Hi Arriy,
Please review this post e2e.ti.com/.../549321.

You can create livelock from either the FLA or SRAM.

Hello Charles
Thank you for your support.

You said livelock can create is below project ?
"SPNU511_7-41_Livelock_Test.zip" from Dave.

Livelock occurred by carrying out this project.
Does it satisfy the Livelock fault injection test of FLA and SRAM ?

Best Regards

Hello Charles.

I know you are very busy,but I am waiting for advice.

Best Regards

Hi Arriy,
For some reason the the post answered by Dave Livingston can not be found when I click the link. Here is another link that talks about generating livelock error. e2e.ti.com/.../549321. I have new assignment and no longer support Hercules forum. Sorry for the inconvenience.

Hello Arriy,

As Charles mentioned, he is no longer supporting Hercules Forum questions, but if you have any additional questions on this topic, please continue to post and I will address them. Please have a look at the new link he provided and let me know if you have any follow on questions. In regard to RAM vs Flash LiveLock, they are two separate operations and would require 2 separate software tests for functionality.

Hello Chuck

Thank you for your answer.

I understand livelock of SRAM /Flash are need 2 separate software tests for functionality.

I can realized livelock of SRAM. But,I can't imagine the way to realize of livelock of Flash.

Please tell me how to way to occur livelock of Flash ?

You give me the link,but I could not know what I wanted to know.

And Charles gave me the link ,but I can't see ARM ALT User's Guide in link. "Sorry! We couldn't find your page." will be indicate.

Best Regards

Arriy,

The link points to an old version of the document you can download the current version from here:

• ARM Optimizing C/C++ Compiler User's Guide tidoc:spnu151
• ARM Assembly Language Tools User's Guide tidoc:spnu118

or access the online versions here:

• downloads.ti.com/.../index.html
• downloads.ti.com/.../index.html

Best Regards,
Christian

Hello Christian
Thank you for your supports.
I was able to see the link


> I understand livelock of SRAM /Flash are need 2 separate software tests for functionality.
> I can realized livelock of SRAM. But,I can't imagine the way to realize of livelock of Flash.
> Please tell me how to way to occur livelock of Flash ?
Please give me advice on the questions above.

Best Regards

Hello Christian.

You said " With this having said there is no reason why you should implement different fault injection tests for the Flash and SRAM as the CPU don't care about the source of the livelock (Fault)." in another thread.(e2e.ti.com/.../2138472

But you also said need separate test in this thread. I'm confused...

You said in another thread,the livelock function is CPU pipeline,in that case I don't think that a separate fault insertion test is necessary.
I think it is sufficient to carry out only one test that can confirm the ESM notification.

Is it a separate test or a only one test which is correct?

Best Regards

Chuck Davenport
Can you please comment why you think that two different tests are necessary:
"In regard to RAM vs Flash LiveLock, they are two separate operations and would require 2 separate software tests for functionality."
Maybe I missed something and I'm wrong with my conclusion.

I understand that there are several reasons (Faults) which could lead to a livelock event (Error):

Two single bit errors in a single unaligned 32-bit Thumb2 instruction
A single bit error in a load instruction plus a single bit error in the "payload"
An undefined instruction on the undef vector

By this logic you would need at least 3 tests for the livelock, or even better 13: ATCM, B0TCM, B1TCM, B0TCM+B1TCM, ATCM + B0TCM, ATCM + B1TCM...

But, the livelock detection mechanism still works on the CPU pipeline and doesn't care about the source of the fault. It also has nothing to do with the hard error cache (I removed the reference from my previous post), nor with the undefined instruction. These are only conditions (Faults) which could lead to the livelock condition (Error) or another mechanism which will work at the same time (hard error cache).
I believe the conditions would stay the same if the CPU core would be configured to exclude the hard error cache. Practically you can't implement the test for the Undefined Instruction condition, as this would require changing the memory content and using POM isn't an option either.

In my opinion and from the CPU livelock detection mechanism perspective it should be enough to implement one of these test.
However, if you look at this from a system perspective you might want to check every condition which will lead to a livelock, then you might need to implement more test. One could also say that one approach is Top-Down and the other Bottom-Up.

At the end it is up to you how you want to handle this, the explanation I gave is just a hint how you could argue. Please also consider to read about this functionality in the ARM Cortex-R4F (r1p3C) TRM, where you will find this information first hand (from ARM).

I believe that there is no true, false or yes and no answer to your question "Is it a separate test or a only one test which is correct?" unfortunately.

Best Regards,
Christian

Christian,

I agree with your overall assessment of the Hard Error Cache and Livelock mechanism, I believe the reason why we have included the test in Flash and RAM elements separately is because we have considered each element separately. In many cases there is overlap in safety mechanisms between elements; for example software test of function with error tests and software test of error paths can be acheived through a shared test for most modules/elements in the device that require them. 

In this case, I agree that the hardware itself is common for the Hard Error Cache with multiple causesconditions for the HW to be used. You could consider for 100% testing you should test each of the different causes of the failure mechanism (including both TCMs and the Flash TCM) or if considered on the resolution of the safety analysis which considers RAM and Flash as separate elements would mean 2 test types or from an understanding of the CPU only one test is OK.

My specific thought is that testing each of the RAM TCMs and the ATCM will test each of the error paths. However, I think if we consider the mechanisms in place that overlap, only executing the RAM TCM test could be justified since things like undefined instructions or other causes of Flash Livelock would be caught by other mechanisms. For sure, if we look at the FMEDA we will see that this mechanism isn't the primary diagnostic responsible for meeting the diagnostic coverage metric,

My recommendation is to include both the RAM hard error cache and livelock as well as the FLASH hard error cache and livelock handling in the same ISR/error handler as I think both will be handled in a similar fashion. This way, at least the test of the ISR instantiation can be exercised as part of the diagnostic testing and verification/validation effort.

All,

Please find an example CCS project attached which will force a lifelock condition.
Flash (BTCM), ARM instruction (LDR), with two single bit faults, one on the instruction and one on the target (address).

Best Regards,
Christian

3817.RM48_Livelock_Flash.zip