cancel
Showing results for 
Search instead for 
Did you mean: 

Problems changing settings for different ADC sources

JohnnyK
Associate II

Hi

I’m having some problems using the ADC on external and internal signals with different requirements.

It and old design having a new MCU (STM32L452RCT), where only the MCU interface are updated, the application are (almost) unchanged. The PCB are in production and all are waiting.

The ADC converts 10 analog signals, 9 extern and one internal, CPU temperature.

The external signals must be converted at a relative high speed, to satisfy some PID loops, and it works fine.

But the internal measurement requires a more slow converting to give the wright temperature.

My guess is that the impedance of the temperature devise are relative high, which will increase the time to charge the sample-hold capacitor.

We use a external voltage reference, therefore I have disabled the internal ref using the macro:

HAL_SYSCFG_DisableVREFBUF()

I use

-        External signals    ADC_SAMPLETIME_12CYCLES_5

-        CPU temperature  ADC_SAMPLETIME_640CYCLES_5

And it works, almost. Some of the internal measurements looks like the signal is floating, not connected to anything. And the values in this situation can be anything between 0 and 4095.

I can’t figure out why this happens, only that it comes if I change the conditions between the different ADC channels. If I don’t change it, I can choose to either have the external signals fulfill the requirements or the internal signal.

I can’t find any indication (function/bool/flag/state) that tell me when the ADC goes wrong, that would make it very easy to filter them away.

Any suggestions?

Br Johnny

6 REPLIES 6

> it comes if I change the conditions between the different ADC channels

What do you mean by this?

JW

JohnnyK
Associate II

9 channel are sampled using ADC_SAMPLETIME_12CYCLES_5 and one using ADC_SAMPLETIME_640CYCLES_5

I do this just when I setup ADC_ChannelConfTypeDef before starting a conversation

sConfig.SamplingTime = ADC_SAMPLETIME_xxxxxxxCYCLES_5

OK so you always perform a single conversion?

Give more details, under which conditions do you observe the problem.

JW

JohnnyK
Associate II

I make single conversions, and not using interrupt or dma.

My application request a set of different measurements, waits for them to be performed, and then uses the result.

Depending on the different states different sets are requested.

The routine performing the measurements call a dedicated function that configurate, start, poll and returns the result.

The cpu temperature value are normally around 1180.

When I run the PCB on my desk the error measurements are 22 - 23 - 24, but when the pcb are mounted in the final machine, that make some electrical field, the error values are 1070-1100.

The same thing happen on the 2 other internal channels, VBAT and VREF.

The error can show up on 2 different ways

  • 10-20 ok results then 1 bad
  • 10-20 bad results and then 1 ok

This all depends on the setup.

Sounds like you inadvertently set up a different channel than you thought.

Try adding something like

if (unexpected reading) {

read out ADC registers content

send them out our store for later inspection

breakpoint here, if possible

}

at the end of temperature readout, and check if all ADC registers have the expected content.

JW

JohnnyK
Associate II

Your comment made me go back and check structs, registers and parameters.

And I made a lot of tests, enabling assert check in HAL library.

I took copies of structures and checked it did not change during conversion.

But everything looks fine, all is good, except the noise numbers.

And there are no way to detect anything goes wrong :(

It turns out that the alignment of the data(/code?) determine if I get

- 3 bad out of 50 or 

- 3 good out of 50

So now I aligned my data (/code) to get 3 bad out of 50, and added a filter.

On Monday we will test if the filter are able to remove the bad values in the read machine.

Thank you for your response.

Br Johnny

Data dump:

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1191, 22.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1190, 22.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp,  23, -269.0 °C BAD

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1193, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1194, 23.0 °C

 CPU Temp,  23, -269.0 °C BAD

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1193, 23.0 °C

 CPU Temp, 1194, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp,  22, -269.0 °C BAD

 CPU Temp, 1193, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 CPU Temp, 1192, 23.0 °C

 Mean CPU Temp, 1121, 5.0 °C, mean distance 132