cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F7 ''LL HAL'' ADC, incorrect register base addresses

peterlauner9159
Associate II
Posted on January 10, 2018 at 17:15

Hi,

In stm32f7xx_ll_adc.h, from revision 1.8 of HAL (stm32cube_fw_f7_v180.zip), the following register base addresses are defined:

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

#define TEMPSENSOR_CAL1_ADDR               ((uint16_t*) (0x1FF07A4C))

#define TEMPSENSOR_CAL2_ADDR               ((uint16_t*) (0x1FF07A4E))

Those addresses do not correspond to the addresses in the datasheet for STM32F746XX, DocID027590 Rev 4, and do not provide correct data either.

V REFIN_CAL Raw data acquired at temperature of 30 °C V DDA = 3.3 V 0x1FF0 F44A - 0x1FF0 F44B

TS_CAL1 TS ADC raw data acquired at temperature of 30 °C, V DDA = 3.3 V 0x1FF0 F44C - 0x1FF0 F44D

TS_CAL2 TS ADC raw data acquired at temperature of 110 °C, V DDA = 3.3 V 0x1FF0 F44E - 0x1FF0 F44F

Looks like a bug in LL HAL for F7.

Regards

Daniel

6 REPLIES 6
Imen.D
ST Employee
Posted on January 11, 2018 at 10:49

Hello

Nilsson.Daniel.002

,

Thanks for highlighting this bug. It is raised internally for fix.

Kind Regards,

Imen

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen
motla
Associate II
Posted on July 10, 2018 at 12:13

Same problem. This has not been fixed so far!

:(

 

:(

Romain

hansSa
Associate

I just found the same problem with STM32F722/723 and stm32cube_fw_f7 version 1.14. Here VREFINT_CAL_ADDR should be 0x1FF07A2A according to the datasheet (and that gives correct data, while 0x1FF07A4A does not).

This sort of information ought to go into the CMSIS-mandated device header, next to UID_BASE etc.

JW

peterlauner9159
Associate II

I reported the original issue here almost a year ago, and that issue is still not fixed. My conclusion is that there is no connection between issues reported here and the QA team at ST, despite ST confirming the issue raised. So while a report here this might speed up the process for other developers it isn't making its way upstream unfortunately.

Maybe they were too busy uglyfying STM32CubeMX ;p