MPC 5674F errata E4396 clarification and questions on workaround

[williamweishaup]

 We have some questions regarding errata e4396 for the MPC5674F processor. While the workaround mentioned in the errata is trivial, the implications and cost of rolling out a new software revision that includes the workaround to our customers can be quite large. Any help that you can provide to better understand the errata and the likelihood of occurrence is much appreciated

1. Why wasn’t this fixed in subsequent silicon revs after it was found?  Is it because the likelihood of its occurrence is so small that it didn’t warrant a fix?
2. Is it “normal” compiler generated code that can cause the condition or is it tight, hand assembly that is more likely the culprit?
3. The wording of the errata is a bit vague regarding the end effect of this condition.  Does the processor (due to the errant fetch address) jump or return via a BLR instruction to an invalid address?  Presumably, this would cause our software to crash making it obvious that something was going on.
4. We’ve never seen a crash due to this condition…is that odd?  Does it only happen at some temperature range?
5. We did a google search for this errata and found one hit that mentioned in a code comment “the workaround doesn’t work”.  We aren’t sure if this is a valid statement or not…can you verify that if implemented, the workaround does work?

[lukaszadrapa]

Hi,

1. I can't comment.

2. There are more conditions which need to be met, so it may affect both kind of codes.

3. Yes, this leads to execution of wrong instruction which may completely destroy user application.

4. There is no way to quantify the probability of the occurrence. It requires an alignment of many internal conditions that the customer cannot control. If the condition occurs, it is likely to occur almost all of the time, however, just because the issue has not been seen, does not mean it may not occur in the future.

5. The workaround was confirmed as correct.

Regards,

Lukas