topic Re: ADC Failure - Failure Modes in S32K

ADC Failure - Failure Modes

sparkee — Thu, 01 Jul 2021 17:28:47 GMT

I seem to be breaking the ADC modules on my boards and I'm not sure how it's happening or why the ADC spits out false readings.

I'm using both ADCs on the S32K144. I sense temperature through the MCP9701 with a 1k resistor in series. On the other ADC I have a current transformer through an op amp rectifier circuit then a filter circuit with three 1k resistors in series and a 100nf cap to ground after each resistor.

One problem I noticed is that I'm using a 2.048V voltage reference but the datasheet seems to say the voltage reference is limited at 2.7V up to Vdda (which is 5V for me, I have vdd and vdda tied together at the chip with separate bypass capacitors).

This setup has been working for over 6 months so far and all readings have been very good so this is confusing. Out of the 60 boards I have produced, I've only had the ADC failure on 3 boards and only in the past week on newly installed boards.

One of the failed boards could have seen a voltage spike on the ADC input, though I would have thought the op amp would have limited the voltage spike from the CT. This spike happened on 5 boards and only 1 board is having ADC problems after I replaced the op amp that was fried.

ADC0 reads a very stable 22 or 23 counts even when grounding the pin.

ADC1 reads a sporadic 700-1100 counts that also does not react to grounding the pin.

ADC0 would have possibly seen the voltage spike.

My question is, what might cause the ADC to fail and how do I prevent this in the future? I understand you have limited info on my circuit so I'm just looking for general recommendations. Do the symptoms I describe sound like ADC failure? All other functions seem to work fine, digital I/O, CAN comms, UART.

Also, is 2.048V reference going to damage the board long term? Do I need to change this? I was attempting to maximize my resolution of the ADC.

These boards has 8 connectors that go to various CTs, a fan, a contactor coil, CAN comms, etc, and it seems that one of the box builds is frying the boards since all 3 of these failed boards were installed in 1 particular box. I haven't confirmed anything yet but I'm afraid to try another board and fry it since we have limited amounts on hand.

Thank you for your time

Re: ADC Failure - Failure Modes

danielmartynek — Wed, 07 Jul 2021 08:17:07 GMT

Hello @sparkee,

It is hard to say, but the low-voltage reference does not seem to be the issue, going below the minimum for the VREFH is more related to not commit with the ADC TUE performance specified.

Can you elaborate on the spike you see there?

The ADC could be damaged by current injection on the ADC input when Vin > VDDA or Vin < VSSA.

Regards,

Daniel

Re: ADC Failure - Failure Modes

sparkee — Thu, 08 Jul 2021 14:19:32 GMT

I ran simulations and was unable to get anything over 2mA but I have to assume that was the issue. Maybe there was a short spike that got through the op amp, though the op amp doesn't seem to be burned up on at least 2 of the 3 boards. Not sure on the 3rd board.

I also haven't completely ruled out ESD but either way it's the same issue.

At any rate, I will put diodes on the next version to mitigate this issue as much as possible.

I did find it strange that it burned up both ADCs and they showed radically different readings.

Thank you @danielmartynek

Re: ADC Failure - Failure Modes

danielmartynek — Thu, 08 Jul 2021 14:39:24 GMT

Hi @sparkee,

Have you tried the ADC modules at different inputs?

Maybe only the pins got damaged.

The Band Gap internal channel should give you a good reference.

BR, Daniel

Re: ADC Failure - Failure Modes

sparkee — Fri, 09 Jul 2021 15:42:12 GMT

Thank you for the suggestion, I will test this next week and report back.

Re: ADC Failure - Failure Modes

sparkee — Fri, 16 Jul 2021 13:50:27 GMT

I attempted to read internal channels and the results did not seem correct to me so I started a fresh project from the ADC example and I'm able to get both ADCs to read correctly now. This means it must be a software problem, but I haven't changed anything related to the ADC reads (at least not on purpose).

I'm going to go back through and see if I can spot the error. I actually hope that it's a software error on my part because we have these units in use in the field so a hardware failure is a much larger problem than a localized software issue.

For reference, here is my ADC init and interrupt:

/***********************************************************************************
* Initialize ADC0
* Channel 10, hardware trigger, 12 bit resolution, single conversion
*
***********************************************************************************/
void Init_ADC0(void)
{
// Initialize for use with calculateIntValue()
// Will hold uS value of timer counter based on #define PDLY0_TIMEOUT
uint16_t delayValue = 0;
/* Configure and calibrate the ADC converter
* - See ADC component for the configuration details
*/
DEV_ASSERT(adConv0_ChnConfig0.channel == ADC_CHN);
ADC_DRV_ConfigConverter(INST_ADCONV0, &adConv0_ConvConfig0);
ADC_DRV_AutoCalibration(INST_ADCONV0);
ADC_DRV_ConfigChan(INST_ADCONV0, 0UL, &adConv0_ChnConfig0);
IRQn_Type adc0IRQ = ADC0_IRQn;
INT_SYS_InstallHandler(adc0IRQ, &ADC0_IRQHandler, (isr_t*) 0);
if (!calculateIntValue(&pdly0_InitConfig0, PDLY0_TIMEOUT, &delayValue)) {
while (1);
}
PDB_DRV_Init(INST_PDLY0, &pdly0_InitConfig0);
PDB_DRV_Enable(INST_PDLY0);
PDB_DRV_ConfigAdcPreTrigger(INST_PDLY0, 0UL, &pdly0_AdcTrigInitConfig0);
PDB_DRV_SetTimerModulusValue(INST_PDLY0, (uint32_t) delayValue);
PDB_DRV_SetAdcPreTriggerDelayValue(INST_PDLY0, 0UL, 0UL, 0);
PDB_DRV_LoadValuesCmd(INST_PDLY0);
PDB_DRV_SoftTriggerCmd(INST_PDLY0);
/* Enable ADC 0 interrupt */
INT_SYS_EnableIRQ(ADC0_IRQn);
}

/***********************************************************************************
* ADC0 used for reading the differential transformer
*
***********************************************************************************/
void ADC0_IRQHandler(void)
{
/* Trigger PDB timer */
PDB_DRV_SoftTriggerCmd(INST_PDLY0);
/* Get channel result from ADC channel */
ADC_DRV_GetChanResult(INST_ADCONV0, 0U, (uint16_t *)&adc0RawValue);
/* Set ADC conversion complete flag */
adc0ConvDone = true;
/* Run detection for every sample */
rtU2.ADC = adc0RawValue;
}

Re: ADC Failure - Failure Modes

sparkee — Fri, 16 Jul 2021 19:44:30 GMT

The plot thickens...

(RECAP) So my custom board has been running this software for almost a year with only minor tweaks and now the ADC has stopped reading correctly. If I put ADC example software on the custom board, ADC works again.

(NEW) If I put MY software on the 144DEV board, it works fine. So my software does not work on my board but does work on the dev board. Both boards work with the example software.

I use the SDK implementation for my software, whereas the example does not utilize the SDK.

I'm still working on it but this is a really strange issue.

Here's my ADC setup. I use the PDB to trigger the ADC every 100us.

@danielmartynek

Re: ADC Failure - Failure Modes

danielmartynek — Thu, 22 Jul 2021 14:25:00 GMT

Hi @sparkee,

Sorry for the delay.

I have had a discussion with my colleagues, maybe a few suggestions.

Can you dump all the MCU registers once you detect the issue and compare it with registers from a working MCU?

Do you see any error flags?

Does the current consumption changes when the issue is detected?

If you replace the MCU with a new, does it work on your board?

If so, you could arrange a NXP factory analysis for the failed part with your local distributor.

Do you measure the VREFH reference continuously?

What is the conversion time of a single conversion?

Maybe you should focus on the difference between the EVB and your board, such as the XTAL.

Do you use Clock monitor?

BR, Daniel

Re: ADC Failure - Failure Modes

sparkee — Wed, 13 Apr 2022 19:41:43 GMT

I'm not sure if this is the same issue but I had to switch from a 144 to a 146 and the software seemed to work fine at times or sometimes not at all or sometime just the ADC stopped working.

I was unable to figure out exactly why it worked occasionally but not always. I finally got a large batch of 146 MCUs and started a project from scratch with 146 instead of changing processor on existing 144 project to 146. I now have 2 code bases but I no longer have these issues.

It seems that the IDE does not do a good job of switching processors. Another issue I had when switching from 146 to 144 is that the flextimers that don't exist in the 144 (FT_mc4 and mc5) keep popping back up in the initialization despite removing them from the list of used components and removing them from the Processor Expert area. Every time the project is closed and reopened, I have to go in and delete them again or the code won't compile.

Thank you for your assistance Daniel.