During ESD testing, we are noticing issues with our ADC values getting stuck. We are using STM32L475VGT6.

[PTana]

No permanent damage has been observed.

Resetting the MCU always results in normal behavior. 

We are using DMA to load all ADC channels. 

We are capturing the ADC values in log files in an external flash IC (AT25DF321A-SH-B).

There are two main types of symptoms:

#1 A previous count value from one channel gets carried forward for all other channels and all ADC values get stuck on this same count value.

#2 all channels get stuck on the same count value, which is not a valid measurement for any channel.

Questions:

#1 there a way to re-initialize the ADC without going through a full reset?

#2 Could this behavior be prevented (e.g., using a different mode for accessing the ADC besides DMA)?

Thanks for your help,

Paul

[PVall]

The initializing code we use is:

 hadc1.Instance = ADC1;

 hadc1.Init.ClockPrescaler = ADC_CLOCK_ASYNC_DIV128;

 hadc1.Init.Resolution = ADC_RESOLUTION_12B;

 hadc1.Init.DataAlign = ADC_DATAALIGN_RIGHT;

 hadc1.Init.ScanConvMode = ADC_SCAN_ENABLE;

 hadc1.Init.EOCSelection = ADC_EOC_SINGLE_CONV;

 hadc1.Init.LowPowerAutoWait = DISABLE;

 hadc1.Init.ContinuousConvMode = ENABLE;

 hadc1.Init.NbrOfConversion = 7;

 hadc1.Init.DiscontinuousConvMode = DISABLE;

 hadc1.Init.ExternalTrigConv = ADC_SOFTWARE_START;

 hadc1.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;

 hadc1.Init.DMAContinuousRequests = ENABLE; 

 hadc1.Init.Overrun = ADC_OVR_DATA_PRESERVED;

 hadc1.Init.OversamplingMode = DISABLE;

 if (HAL_ADC_Init(&hadc1) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure the ADC multi-mode 

 */

 multimode.Mode = ADC_MODE_INDEPENDENT;

 if (HAL_ADCEx_MultiModeConfigChannel(&hadc1, &multimode) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_8;

 sConfig.Rank = ADC_REGULAR_RANK_1;

 sConfig.SamplingTime = ADC_SAMPLETIME_247CYCLES_5;

 sConfig.SingleDiff = ADC_SINGLE_ENDED;

 sConfig.OffsetNumber = ADC_OFFSET_NONE;

 sConfig.Offset = 0;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_11;

 sConfig.Rank = ADC_REGULAR_RANK_2;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_12;

 sConfig.Rank = ADC_REGULAR_RANK_3;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_13;

 sConfig.Rank = ADC_REGULAR_RANK_4;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_14;

 sConfig.Rank = ADC_REGULAR_RANK_5;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_15;

 sConfig.Rank = ADC_REGULAR_RANK_6;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

 /**Configure Regular Channel 

 */

 sConfig.Channel = ADC_CHANNEL_16;

 sConfig.Rank = ADC_REGULAR_RANK_7;

 if (HAL_ADC_ConfigChannel(&hadc1, &sConfig) != HAL_OK)

 {

  Error_Handler();

 }

Thanks,

-Phil

[TDK]

It looks like you're performing ADC conversions as fast as possible. It's possible the DMA cannot keep up and causes either the ADC or DMA to abort.

Does this have anything to do with ESD testing? Do you only see this behavior while actively performing an ESD test on a pin?

[PVall]

TDK,

Thanks for the quick response!

The errors are only seen during ESD testing.

Yes, we can try to slow down the ADC conversions.

I do have a HAL_ADC_ErrorCallback(ADC_HandleTypeDef* hadc1) that isnt firing.

Thanks,

-Phil

[Amel NASRI · Accepted solution]

Hello @Community member​ & @Community member​ ,

There is a known behavior seen when the chip is not respecting the datasheet conditions. Here we speak about the following condition:

 

When this variation is very high compared to the 50 mV, the ADC conversions get stuck.

This variation can be due to the pins close to VSSA that are not ESD protected and where there is a coupling energy.

So, what I suggest is to analyze deeply the connections for pins like PC3 and PC2 which are very close to VSSA and make sure you apply needed ESD protections.

You have also to be aligned with PCB recommendations provided in AN4555 mainly for decoupling capacitors.

If you think that you are respecting the previously mentioned condition even under ESD tests, I think that your problem is a different one.

-Amel

[PTana]

Thanks for your response Amel! I have some follow-up questions:

1. All of our lines which are exposed to ESD (e.g., connected to external inputs/outputs have TVS protection at the expected source of ESD (i.e., not near the MCU pins). Are you recommending that we place TVS on lines adjacent to the VSSA pin to protect against VSSA bouncing more than 50mV?
2. Which of the recommendations regarding decoupling caps in the app note and datasheet are most pertinent to mitigating this issue with ADCs getting stuck (e.g., use of a large enough cap value)?
3. It appears that the app note recommendations (section 7.4) contradict the MCU datasheet as section 6.1.6 in the MCU datasheet recommends placing a 10nF cap and 1uF cap between VDDA and VSSA, whereas the app note recommends using a 100nF cap and a 10uF cap across all supply pairs, and seem self-contradictory. 
   1. What would be a better choice in cap values for addressing this ESD issue?
   2. Why does the datasheet recommending using decoupling caps of 4.7uF and 100nF across VDD and VSS, but 1uF and 10nF across VDDA and VSSA (e.g., why is it apparently better to use smaller decoupling caps on the analog side?)?
4. What are the common symptoms of ADCs getting stuck due to excessive variations in different ground pins (e.g., have others seen the behavior of all ADC outputs copying the same count value as one of the ADC outputs, and then all ADC outputs getting stuck on this same count value?)?

Thanks again for your help,

Paul

[Simon V.]

Hello Paul,

Q1 :All of our lines which are exposed to ESD (e.g., connected to external inputs/outputs have TVS protection at the expected source of ESD (i.e., not near the MCU pins). Are you recommending that we place TVS on lines adjacent to the VSSA pin to protect against VSSA bouncing more than 50mV?

A1: Yes we suggest you to place TVS on adjacent lines to VSSA pin. What is the kind or topology of theses lines please?

Q2 :Which of the recommendations regarding decoupling caps in the app note and datasheet are most pertinent to mitigating this issue with ADCs getting stuck (e.g., use of a large enough cap value)?

A2:Please follow the getting started guide regarding the capacitor size. We did not noticed correlation between the VSSA boucing and the decoupling capacitor size.

Q3:It appears that the app note recommendations (section 7.4) contradict the MCU datasheet as section 6.1.6 in the MCU datasheet recommends placing a 10nF cap and 1uF cap between VDDA and VSSA, whereas the app note recommends using a 100nF cap and a 10uF cap across all supply pairs, and seem self-contradictory.

A3: I agree with your comment, thank you for your feedback, we will update the application note to match the datasheet values

Q3.1 : What would be a better choice in cap values for addressing this ESD issue?

A3.1 : please see answer A2.

Q3.2 :Why does the datasheet recommending using decoupling caps of 4.7uF and 100nF across VDD and VSS, but 1uF and 10nF across VDDA and VSSA (e.g., why is it apparently better to use smaller decoupling caps on the analog side?)?

A3.2 : the power consumption of the analog side is smaller than the other side of the MCU: so smaller capacitors can be used.

Q4: What are the common symptoms of ADCs getting stuck due to excessive variations in different ground pins (e.g., have others seen the behavior of all ADC outputs copying the same count value as one of the ADC outputs, and then all ADC outputs getting stuck on this same count value?)?

A4: When excessive variation voltage occur in different ground, the ADC digital core circuitry is reset. The ADC digital interface with the MCU is reading the last converted value. The ADC should be fully initialized again to execute the start-up sequence of ADC core circuitry.

Can you confirm us which level of ESD strike do you apply ? We tested nucleo board up to several kV in our lab without issue.

Kind regards,

Simon