TMS570LS1114: processor hangs during CPU self-test + ADC_PIN_UNDETERMINED

Hi Nate,

Can you provide more info on your first question? During CPU BIST, the CPU is taken offline and, upon completion, the CPU is reset. Because of this, your question leaves me curious as to which CPU self-test you are referring? Are you referring to the CCMR4 self-test? If so, what do you mean the self test while handling an ESM error? i.e., if you are running the CCM selftest, the CPU would not necessarily be doing anything else since this is a foreground function. Do you mean there is an ESM error when CCMR4 self-test is executed? Is this in customer code, Halcogen code, or within a SafeTI Diagnostic Library function call? Can you post the code or, if related to the SDL, post the function call that causes it and the line number of the ESM handler where it gets hung?

For your second question, you mentioned the same circuit on each ADIN pin? I assume they are providing different voltages and loading to the ADIN pins? Since this test relies on internal voltage divider networks and supplies together with the connection to the pin, input voltages can shift some of the results of the intermediate calculations causing the indeterminate result. This truly means that the input is indeterminate. In most cases this will be OK but to be sure, can you provide the input voltages/loading on the pins getting this result vs. the ones that are not? This may help in understanding the results.

Hi Chuck. I'm the one Nate has been working with.

I have been going thru the learning curve of trying to understand the proper handling of ESM generated interrupts due to run time faults found by lock-stepped processor checking. I have also been playing with the SafeTI diagnostics library to understand how that works, maybe to do some self tests on power up of modules used in my safety algorithm.

The animated demo (http://www.ti.com/ww/en/functional_safety/safeti/safeTI-animation.html

For some reason my post after weblink did not post. Reposting:

The animation shows the ESM interrupt handler running a CPU Self Test. If passed it clears nError, resets, and continues on.
This CPU self test is the same one as generated by Halcogen? This self test should be done for any ESM interrupt?

I have only been able to use the CPU Self Test in bootloader project, not application project. When in application project, code hangs. Since you can't use it with a debugger I'm unable to figure out why it hangs.

As for ADC pin testing with SafeTI DL, I have been trying to figure out what signal conditioning circuitry can be on the input to ADC pins to get consistent test results. It does seem to detect shorts to ADC Vref H/L. If it is ok to determine an ADC pin is OK if self test returns either ADC_PIN_GOOD or ADC_PIN_UNDETERMINED, than I will go with that premise.

Hello James:

James Salisbury4 said:

The animation shows the ESM interrupt handler running a CPU Self Test. If passed it clears nError, resets, and continues on.
This CPU self test is the same one as generated by Halcogen? This self test should be done for any ESM interrupt?

The demo is showing a CPU fault as detected by the CCM during run-time and not the CPU self-test. In the event of a CPU fault in either of the two lockstep cores, the CCM will notify the system by means of the ESM and since the CCM fault type is a group 2 error, it results in an NMI and automatic assertion of the nERROR pin. This requires then that it be serviced in some way. In the case of a CPU fault of this type, a normal operation is to force a reset which will then cause the application to start up again including the boot time LBIST (CPU logic built in self test) which will identify a fault if the fault is a permanent failure rather than a transient fault. If it IS permanent, a possible outcome is to then have the system enter/transition to a safe state that could be powering the MCU down, holding it in reset, or somehow taking the MCU offline since the CPU cannot be trusted due to an internal fault of some kind. Note that the reaction to the fault is 100% up to the system level need and requirement noting that the CPU operation is known to be questionable due to the identified internal fault.

Note that this is in response to the specific type of fault that occurred. For other fault types, it is, again, up to the system requirements to determine the proper response. So in the case of a LBIST fault at power up as noted above, you may want to only enter the safe state when running as a result of a previously identified CPU fault such as the case we described but, if on a normal power on reset execution of LBIST (CPU self test) with no prior CPU fault, you may choose to repeat the CPU self-test in order to confirm if the fault was a transient or permanent fault. If permanent, then, as before, go to a safe state.

If, we are discussing some other type of fault such as a RAM or Flash double bit error/uncorrectable error, comm channel error, NHET error, clock error, etc., you will need to assess the impact to the system operation and determine what course of action to take and whether the error is recoverable/correctable or if it is not and requires a move to a safe state or device reset.

In regard to the ADC self-test and the UNDETERMINED return status. This can happen because of the loading on the ADC/input voltage at the time of the test. If you can provide some additional information regarding your ADIN circuit (schematic snapshot would be ideal) along with the input voltage at the time of the conversion, we should be able to determine the reason for the status report and then decide if it is acceptable or not.

I did some more testing on a typical thermistor input signal conditioning circuit used. Here are the results.

Opamp is OPA2171AIDR.

ADREFHI is 4.5V. ADREFLO is 0V. VCCAD is 5V. VSSAD is 0V.

Circuit is for thermistor input, placing thermistor between VIN and GND.

For VIN<3.1V, adc_pinstatus returns ADC_PIN_GOOD.

For VIN>3.1V, adc_pinstatus returns ADC_PIN_UNDETERMINED.

 

              adcConfig.adc_channel = 12;

              adcConfig.adcbase = sl_adcREG1;

 

              retVal = SL_SelfTest_ADC(ADC_SELFTEST_ALL, FALSE, &adcConfig, &adc_pinstatus);

 

              if (1 == retVal)

              {

                     if (ADC_PIN_GOOD == adc_pinstatus)

                     {

                           selftest_passcnt++;

                     }

                     else

                           selftest_failcnt++;

 

              }