Skip to main content
MarlonM
MarlonM
Associate
April 3, 2023
Solved

What's the cause why ADC raw reading value became higher after NVIC_SystemReset?

  • April 3, 2023
  • 6 replies
  • 1970 views

MCU: STM32G474 (100 pins)

PIN: PD12 configured as ADC input with 12-bit resolution

PIN: PE1 configured as GPIO_Input to trigger software reset thru NVIC_SystemReset()

How to duplicate:

1.) Inject voltage on PD12 and monitor the ADC raw reading.

2.) Trigger the reset at PE1.

3.) Read the raw reading at PD12.

Expected Result:

Raw reading should be almost the same.

Actual Result:

The raw reading became higher.

Example: Previously, the ADC raw reading at PD12 was 12400. Then after the reset, it became 12800.

So far, only this pin was observed to have this kind of behavior.

Do you have any experience with this kind of behavior? Have you determine the cause?

This topic has been closed for replies.
Best answer by waclawek.jan

> Is it normal to add a delay? How do you determine the needed delay?

The ADC startup procedure is described in ADC Deep-power-down mode (DEEPPWD) and ADC voltage regulator (ADVREGEN) subchapter of ADC chapter in RM. It refers to the delay given in datasheet, as er the screenshot you've posted.

I would expect it does affect the calibration; however, I don't know why would that affect only one pin's reading, though, nor why would that be different from powerup. Maybe this all depends on some minute details of your particular application.

> Though, this delay should be handled by the auto-generated code from STM32Cube.

Maybe it is. I don't use Cube, but it's open source so you can look it up easily.

JW

6 replies

waclawek.jan
waclawek.jan
Super User
April 3, 2023

How exactly do you configure/start ADC and how do you take the readouts?

Which readout is correct, 12400 or 12800?

What is VREF+ source, describe your hardware.

Try to find explanation in Errata and AN5346.

JW

MarlonM
MarlonMAuthor
Associate
April 3, 2023

Hi JW,

Thanks for the info.

The ADC is configured as follows:

(1) Initialize

(2) Calibrate

(3) Enable

(4) Convert

This configuration is also within the main() function.

The triggering and conversion are done considering what's written on the errata (ES0430).

The VREF+ source is handled by an LDO circuit with a ripple of less than 10mVpp.

The expected readout is around 12400.

Power recycling would still result in the same value, 12400.

With continuous polling, the readout is still around 12400.

But upon Software Reset thru NVIC_SystemReset() function,

this 12400 readout would become 12800.

Except for this ADC (PD12) pin, the other ADCs' readouts being monitored are still the same after the software reset.

Is there a way to debug the NVIC_SystemReset()? What part of the code should I look at?

Thanks in advance.

waclawek.jan
waclawek.jan
Super User
April 3, 2023

Doesn't ring any bells, sorry.

For this sort of problems, you may try to contact ST directly, through FAE or the web support form.

JW

MarlonM
MarlonMAuthor
Associate
April 4, 2023

Just want to share that by injecting an additional delay in the initialization of the ADC, the error improved. The ADC init sequence becomes:

(1) Initialize

(2) >20us Delay (manually added)

(3) Calibrate

(4) Enable

(5) Convert

and it seems related to the ADC start-up time:

0693W00000bhT4kQAE.pngThough, this delay should be handled by the auto-generated code from STM32Cube.

Any experience with this? Is it normal to add a delay? How do you determine the needed delay?

or any material that may explain the delay needed before the ADC calibration? tia

waclawek.jan
waclawek.janBest answer
Super User
April 4, 2023

> Is it normal to add a delay? How do you determine the needed delay?

The ADC startup procedure is described in ADC Deep-power-down mode (DEEPPWD) and ADC voltage regulator (ADVREGEN) subchapter of ADC chapter in RM. It refers to the delay given in datasheet, as er the screenshot you've posted.

I would expect it does affect the calibration; however, I don't know why would that affect only one pin's reading, though, nor why would that be different from powerup. Maybe this all depends on some minute details of your particular application.

> Though, this delay should be handled by the auto-generated code from STM32Cube.

Maybe it is. I don't use Cube, but it's open source so you can look it up easily.

JW

MarlonM
MarlonMAuthor
Associate
April 5, 2023

Been using ADC channels: ADC1, ADC2 and ADC3

Upon checking the other ADC channels being used, found out that the whole ADC3 channel was affected.

The code is being built on a lower version of STM32Cube (1.5.1) and the delay being used was 10us.

When compared to the latest version of STM32Cube, the delay is now 20us.

This might be a case of marginality issue.

Thanks JW!

Terms & ConditionsAccessibility statement