Voltage and Temperature calculation macro not responding on STM32H563ZIT6

[VThan.2]

Hello Community,

I am using 2 function calls 

__LL_ADC_CALC_VREFANALOG_VOLTAGE();
__LL_ADC_CALC_TEMPERATURE_FLOAT();

My implementation:

uhADCxConvertedData_VrefAnalog_mVolt = __LL_ADC_CALC_VREFANALOG_VOLTAGE(aADCxConvertedData[1], LL_ADC_RESOLUTION_12B);

temperature = __LL_ADC_CALC_TEMPERATURE_FLOAT(uhADCxConvertedData_VrefAnalog_mVolt, aADCxConvertedData[2], LL_ADC_RESOLUTION_12B);

I am seeing the above macros not respond and there is a hard-fault whenever I call the above functions. Any help would be appreciated. 

Thank you

[unsigned_char_array]

Have you checked this topic?
https://community.st.com/t5/stm32cubeide-mcus/ll-adc-calc-temperature-hardfaults-ts-cal1-ts-cal2-read-as-zero/td-p/77106

A macro should not result in a hardfault error unless it refers to an illegal memory location or divides by zero or something. What do you see when you debug the code and step through it? What are all the values? If this doesn't help you please upload your ioc file.

[Billy OWEN]

Hi @VThan.2 

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.

Regards,

Billy

[Andrew Neil · Accepted solution]

---

@VThan.2 wrote:

there is a hard-fault whenever I call the above functions. 

---

So what have you done to debug the Hard Fault?

https://www.st.com/resource/en/user_manual/um2609-stm32cubeide-user-guide-stmicroelectronics.pdf

[VThan.2]

Thank you this worked. 

[unsigned_char_array]

What was the problem? How did you fix it?

[jllomibao]

I am getting the same issue. It looks like 0x08FFF814 is not a valid address.

[benjacam]

I am also seeing this exact problem with STM32H573.

I see a hard fault just when reading TS_CAL1 with this code:

volatile uint16_t cal = *(volatile uint16_t*)0x08FFF814UL;

I've debugged the hardfault (well, chatgtp did the decoding..)

HFSR=0x40000000

CFSR=0x8200

BFAR=0x8fff814

1. HFSR = 0x40000000

• Bit 30 (FORCED) = 1 → This means a configurable fault (like bus/memory/usage fault) escalated to HardFault.

• Other bits are 0 → not a vector table read fault.

So: the real cause is in CFSR, not in HFSR.

---

2. CFSR = 0x8200

The CFSR is 32 bits, split into three sub-registers:

• [31:16] UsageFault Status (UFSR)

• [15:8] BusFault Status (BFSR)

• [7:0] MemManage Fault Status (MMFSR)

Let’s decode 0x8200:

• Binary: 1000 0010 0000 0000

• Bits [15:8] = 0x82 → BusFault Status = 1000 0010

So BFSR bits:

• Bit 7 (BFARVALID) = 1 → BFAR holds the faulting address.

• Bit 1 (PRECISERR) = 1 → Precise data bus error.

• Others = 0.

Thus: a precise bus fault occurred while accessing BFAR address.

No MemManage or UsageFault bits are set.

---

3. BFAR = 0x08FFF814

That’s exactly the TEMPSENSOR_CAL1_ADDR you pasted earlier.
So: the fault was triggered when the CPU tried to read the calibration constant at 0x08FFF814.

===

However, if I connect to the device using stm32programmer, I can see those addresses are written:

Is there a requirement to enable a specific clock or power domain to read these registers?

[benjacam]

... I also just worked out why...

In this example linked below, there is a function MPU_Config which makes the area of flash containing trims un-cacheable. Adding this function results in no faults accessing the trims.

https://github.com/STMicroelectronics/STM32CubeH5/blob/f6cd6bcde45b717a229f73ded6258776e9a07a3e/Projects/NUCLEO-H533RE/Examples/ADC/ADC_MultiChannelSingleConversion/Src/main.c