Maximum time required to read the internal temperature

[Jack5]

Hi,

I am able to read the mcu temperature but I want to know the maximum worst-case time required to read the internal temperature of stm32h743.

The clock for the ADC is configured as 76 MHZ. Does that mean that 1 ADC cycle is 0.013 uS (1/76M) ?

#define ADC_SAMPLETIME_1CYCLE_5          (LL_ADC_SAMPLINGTIME_1CYCLE_5)  

And does the above macro mean that the sample time will be 1.5 * 0.013 uS = 0.019 uS

The datasheet says that the minimum sampling time should be greater than the stabilization time, but I am not bale to find the stabilization time. Could you please tell me the minimum sampling time I should set to read reliable temperature values ?

From the datasheet, the total time for conversion is given by the formula: "sampling time + 7.5 ADC cycles."

If you set:
sConfig.SamplingTime = ADC_SAMPLETIME_32CYCLES_5;

then the time taken for the result to be available after calling `HAL_ADC_Start()` will be calculated as:

Total Conversion Time=(76×10^6​)×(32.5+7.5)

Is this correct?

Regards,

[Jack5]

Hi @waclawek.jan ,

The issue was found to be because of the delay function. Though 1 ms was given it was not providing a delay of 1 ms due to the reason explained below:
https://forums.freertos.org/t/does-vtaskdelay-1-delay-up-to-one-tick-or-circa-one-tick/7640

Also, I tested this with a busy wait delay implementation using the cycle counter and it looks like it is taking around 15 uS to complete the conversion but as per my calculation the conversion time should be 10.423 uS. Should we consider any other overhead ?

[waclawek.jan]

Interesting.

Loopdelays are usually written so that they provide delay which is *at least* the specified value. Granularity means that it may be longer, e.g. with 1ms delay generated with 1ms granularity often surprisingly takes systematically 2ms if called under certain circumstances.

If FreeRTOS indeed provides a delay function which may result in delay *shorter* than specified, that is IMO a serious design flaw. Not that I'm surprised, just disgusted.

> Also, I tested this with a busy wait delay implementation using the cycle counter and it looks like it is taking around 15 uS to complete the conversion but as per my calculation the conversion time should be 10.423 uS. Should we consider any other overhead ?

I don't know what exactly are you doing, but theoretically your figure 10.4us is correct and extra 4-5us sounds too much at 76MHz even with Cube. Maybe I'm overlooking something, I don't use Cube nor H7.

JW