RM57L843: Question about applying Errata DCC#24 workaround?

Hello Canfoderiskii,

I am investigating this question and will get back with you early next week.

I have a similar question in regards to DCC#24, which is an errata for TMS570LC4357. 

If I am using the DCC detection result from the DCCSTAT register, do I still need to apply the subtraction workaround?

Static frequency offset can be removed by making two measurements and subtracting. The
sporadic offset can be removed by making multiple measurements and discarding outliers -- an odd
filtering algorithm.

It is not clear whether the fixed offset is an issue when the application reads the counter or for the DCC countdown itself.

Michael,

The issue is in the clocking of the counter which may be subject to clock synchronization issues. This is because the logic is being driven by VCLK and the counters are being incremented by their associated source clocks. This leads to potential errors in cycle counts due to partial clock cycles or transitioning counts when being read. This will potentially impact both the status bits as well as direct read of the counters. Since this is generally an issue that will result in false fails and not false passes, I would generally recommend that you could use the status bit for normal checking and on a fault notification, perform the work around test to identify if the fault notification was true or not. The other option is to use the DCC in continuous monitoring mode rather than single shot. In continuous mode, the error is averaged automatically due to the multiple tests over time.

thank you for the detailed reply.

Chuck,

Thank you for the response. I hope the recovery efforts are going well for
you and your family.

1.) For the purposes of clarification because of thread hijacking:
I am using the TMS570LC4357, not the RM57L843. DCC#24 and SSWF021#45 are an
issue for my application because the errata is the same for my processor. I
am trying to implement the DCC#24 workaround to fix the detailed SSWF021#45
workaround provided by TI.

The workaround suggestion provided in response to Canfoderiskii's question
is to use the DCC continuous mode and implement a continuous application
monitor. My system already has a continuous monitor in the form of an
external watchdog. If the clocks are wrong, the external watchdog monitor
will cause the processor to reset when the application fails to kick on
time. I cannot add a new continuous monitor to my system. What I want to do
is isolate a real PLL issue at power-on reset and stop application
processing instead of letting the issue persist until the watchdog trips.

2.) Further questions I have about the current errata documentation and what
has been said in the thread so far:

a.) Does the detailed explanation of the SSWF021#45 workaround with
associated source code need to be updated?

b.) It is not clear how I should implement the DCC#24 workaround in
single-shot mode by "taking multiple measurements and subtracting the fixed
offset or discarding outliers" as documented in the errata. Does that mean
I should read the DCC counts when "Done" is signaled and perform these
actions? I am not sure when I should read the counts otherwise. How many
times should this be done before I can call the PLL good? Does it matter
whether the "Error" bit is set since, as you suggested, there is some
possibility for a false pass?

c.) If I change the DCC to use continuous mode, how long do I need to let
continuous run before I call the PLL good? If I do get an error in
continuous mode, how many errors are acceptable before I know the PLL is
bad? Does continuous mode eliminate the false passes and false failures?

Michael,

Michael DeClerck said:

The workaround suggestion provided in response to Canfoderiskii's question  is to use the DCC continuous mode and implement a continuous application  monitor. My system already has a continuous monitor in the form of an  external watchdog. If the clocks are wrong, the external watchdog monitor will cause the processor to reset when the application fails to kick on time. I cannot add a new continuous monitor to my system. What I want to do
is isolate a real PLL issue at power-on reset and stop application processing instead of letting the issue persist until the watchdog trips.

As with most of our answers, there are always system level concerns and requirements that can come into play. In this, case you have mentioned that you are also using an external WD for continuous monitoring of the device and program execution. If this is the case, and you feel your WD period is accurate enough to capture the degree of change required in your system, then it is certainly a valid mechanism. I would ask, however, what that backup do you have? i.e., if there is a fault in the WD circuit where it fails to trigger an error, is there a secondary mechanism or even, perhaps, a diagnostic mode for the WD where you can determine latent faults prior to the need of the error detection?

In the end, this comes down to the safing of the Clock element of the device. For this purpose we have several different diagnostics highlighted in our Safety Manual. Among these are CLK3 which is the use of the DCC AND CLK5C which is the use of an External WD. Both provide a significant coverage that will meet the needs of an ASIL-D or SIL3 system requirement. Note that it is highly recommended that a sequence aware WD be used for any external WD implementation.

If we are to consider the SSWF021#45 errata, there is a need to check the frequency right after it has locked. It is not required to use the DCC for this. For example, you could also utilize the RTI by setting up a loop where you could manually calculate how many cycles it would take to execute it at the expected PLL frequency. If you start the RTI counter (select the source as different than the PLL, OSCIN as example), then execute a straight path or looped SW flow with a known cycle count, then read the RTI counter and compare to the expected values based on the number of RTI src clocks vs system clocks for code execution. This, in effect, would be the same operation as the DCC without the worries of the clock sync issues. An alternative, would be to combine a system test of the WD together with a test of the PLL. i.e., setup a delay loop to automatically trigger the WD. If the delay count is incorrect after the warm boot/reset from the WD, then the PLL had an issue. The final solution really depends on your system capability and your ability to utilize the resources at hand to satisfy the testing.

Michael DeClerck said:

a.) Does the detailed explanation of the SSWF021#45 workaround with
associated source code need to be updated?

Not in my view.

Michael DeClerck said:

b.) It is not clear how I should implement the DCC#24 workaround in  single-shot mode by "taking multiple measurements and subtracting the fixed offset or discarding outliers" as documented in the errata. Does that mean I should read the DCC counts when "Done" is signaled and perform these actions? I am not sure when I should read the counts otherwise. How many times should this be done before I can call the PLL good? Does it matter whether the "Error" bit is set since, as you suggested, there is some possibility for a false pass?

I would suggest that you treat the counts for each SRC counter in much the same way you would filter the inputs from an ADC input. i.e., take several measurements, calculate the averages for each counter, then compare them. I agree that the error/pass flag would have little meaning in this context.

Michael DeClerck said:

c.) If I change the DCC to use continuous mode, how long do I need to let continuous run before I call the PLL good? If I do get an error in continuous mode, how many errors are acceptable before I know the PLL is bad? Does continuous mode eliminate the false passes and false failures?

Given the DCC is doing a cycle based comparison, I would consider the time it would take to run a significant number of counter0 cycles. The number of measurements is really dependent on the number that you are comfortable with at the system level. Given the speed at which the devices run, there could be significant sample taken very quickly.

Chuck,

Thank you for the response.

When you say that the the detailed explanation of the SSWF021#45 workaround with associated source code does not need to be updated, do you mean that this document correctly implements the workaround for SSWF021#45?

www.ti.com/.../spna233a.pdf

Thanks,

Thank you!