STM32G031K8 ADC Vref INT

[danielbathtub]

Hi, I am trying to measure the Vref+ voltage using the ADC on the STM32G031K8. I looked at the latest datasheet saying that the VREF CAL value is the memory adress given below. 

So, when I run this code through the debugger,

1.) It gives me a hard fault handler on the dereferencing of the VREF_CAL pointer. 

2.) When I remove the dereferencing code, the program runs without the hard fault handler. 

Can anyone please explain this or assist with this problem ?. As the supply voltage in my application varies and an accurate ADC is of critical importance and safey.

Thanks, 

Daniel  

[danielbathtub]

More Detail: 

I am using a NUCLEO-32 DEV board with the STM32G031K8 MCU.

[AScha.3]

Hi,

>I am trying to measure the Vref+ voltage using the ADC 

- this is basically nonsense ! It always will give you 0xfff , because it is the internal ADC positive reference.

You have to calculate (!) the Vref+ by measuring a fixed voltage, here the VREFINT.

+ dont forget :

+

+ 

btw : VREF_CAL seems to be int16 , not int32  .

++ read the rm !

[danielbathtub]

>btw : VREF_CAL seems to be int16 , not int32 

Thank you, this seems to be a viable solution to the problem. Now where did you get this information from ?. 

I couldn't find this in any datasheet or reference manual... Now I know the ADC conversion result is a 12-bit value, yet this is stored in a 32-bit register... I've only really seen 16-bit registers in TIM14. The reference manual seems to suggest there is only 32-bit registers used for the ADC configuration, ect,ect. 

[waclawek.jan · Accepted solution]

Hardfault is caused by dereferencing the non-word-aligned 0x1FFF7FAA as a word (32-bit). 

ST unfortunately does not define symbols to use the calibration values in CMSIS-mandated device headers.

#define VREFINT_CAL_ADDR ((uint16_t*) (0x1FFF75AAUL))

JW

[AScha.3]

>Now where did you get this information from ?

Just from the address , 2 Byte range -> int16 ; as Jan marked in red .

[danielbathtub]

Thanks Jan, 

That makes sense and solves my problem.

Now I understand, why the value is uint16_t* . 

Thank you for the additional information about the Hardfault handler.

Regards, 

Daniel