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,

[waclawek.jan]

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

No, there's an additional prescaler, ADCx_CCR.PRESC. You should not set it so that ADC clock is 76MHz as maximum ADC clock is 50MHz (with appropriately set BOOST bits -- in rev.Y the max. ADC clock is lower).

> 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.

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

That's unfortunately misleading and valid only if you select 14-bit conversions. The conversion time depends on selected resolution (and also if the sampling time was selected the shortest 1.5cycle or not):

JW

 

[Jack5]

Thank you @waclawek.jan  for your detailed reply.

So, I am using a prescaler setting of ADC_CLOCK_ASYNC_DIV2, a resolution of ADC_RESOLUTION_16B, and a sampling time of ADC_SAMPLETIME_387CYCLES_5. I calculated that the maximum time for a single conversion should be approximately ~10.5 µs, and I hope this is correct.

However, I have noticed that sometimes HAL_ADC_PollForConversion(&Adc3Handle, 0); fails with the error code HAL_TIMEOUT. It works about 90% of the time, but occasionally throws this error. The pseudocode is given below:

 

 

 

while(1)
{
 ret = HAL_ADC_Start(&ADC3);
 if (HAL_OK != ret )
 {
 Error_Handler();
 }
 Delay_ms(1);

 ret = HAL_ADC_PollForConversion(&ADC3, 0);
 if (HAL_OK != ret )
 {
 Error_Handler();
 }
 Temperature = HAL_ADC_GetValue(&ADC3);
}

 

 

Why does it fail sometime ? Is 1 ms of time not enough for the conversion ? Does the ADC conversion have a dependency on anything else happening within the system at the same time ?

 

[waclawek.jan]

Unlikely.

Is the error timeout?

Cube/HAL is open source, so you can track what could cause the error, and also in case of the error observe the ADC registers (especially status register) to gain more insight.

JW

[Jack5]

Hi @waclawek.jan , Thank you for your reply.

Yes, The error code returned is 0x03 which is HAL_TIMEOUT.

This is returned from the point marked below and the value of ISR and ADC3_CSR is same which is 0x1003.

This means that the EOC flag is not set.

Can I please ask if connecting a J-link will have any impact on the timing ?

I also see that if I put a breakpoint on line number 10, the EOC flag is set to 1 (see snapshot below) but as soon as I step into the function I see that it clears and then returns a HAL_TIMEOUT.

After stepping into the function (control is now at the first line in function HAL_ADC_PollForConversion)

 

 

 

[waclawek.jan]

> Can I please ask if connecting a J-link will have any impact on the timing ?

Should not. While the debugger is part of the processor and shares its bus system, transactions through it should be rare relatively to the overall performance of the processor, as commands/data to/from the on-chip debugger to the "debugging pod" traverse through a relatively slow serial interface (SWD).

However, while *timing* may not be affected significantly, reading registers through the debugger does have consequences: in your case, reading ADC registers, namely ADC_DR, using the debugger, clears the EOC bit:

JW

 

[Jack5]

Hi @waclawek.jan ,

Thank you for your reply.

Hmm..I see your point and I understand why I am seeing this during debugging.

But should this issue happen if the debugger is just connected and the ADC3 registers (including ADC_DR)are not opened/viewed ? No breakpoints/stepping. I have flashed the code and then just did a reset to run the code. The debugger is still connected and I can see the issue happening :(

[waclawek.jan]

> But should this issue happen if the debugger is just connected and the ADC3 registers (including ADC_DR)are not opened/viewed ?

This is hard to tell definitively as it depends on the debugging setup which is seldom perfectly described, but yes, it sounds unlikely. A definitive test would be, if you'd indicate the error e.g. using a LED, and run it with debugger disconnected.

I'm not sure what could be the real/primary cause of your problem. Maybe you could try to start a new, absolutely minimal project, with only the ADC polling, and if the problem is reproducible there, post it.

JW

[Jack5]

Thank you @waclawek.jan  for your reply. 

I see that it is happening even without the debugger connected. so it is not due the debugger.

I will try with a minimal project and let you know.

In the meantime, can you think of any corner case scenarios when the EOC flag cannot be set in the stipulated time ?

Eg:- Any hardware fault, can LL_ADC_REG_StartConversion(hadc->Instance); immediately reflect the values in the registers or does it take some time to update the registers ? 

[waclawek.jan]

> can you think of any corner case scenarios when the EOC flag cannot be set in the stipulated time?

Not really.

JW

[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