STM32L051 Reference manual & stm32l051xx.h mismatch ???

[jan]

Posted on December 30, 2015 at 12:33

Hi,

I have a question regarding SYSCFG_CFGR3bit definition. I'm using stm32l051xx.hV1.4.0 and Reference manual RM0377 /DocID025942 Rev 4. Some bits seems to be defined in reserved area of SYSCFG_CFGR3. E.g.: SYSCFG_CFGR3_EN_VREFINT - bit0 or SYSCFG_CFGR3_VREFINT_ADC_RDYF - bit28 Am I missing something basic? Any advice is welcomed :) Please see below for comparison:

/***************** Bit definition for SYSCFG_CFGR3 register ****************/
#define SYSCFG_CFGR3_EN_VREFINT ((uint32_t)0x00000001) /*!< Vref Enable bit*/
#define SYSCFG_CFGR3_VREF_OUT ((uint32_t)0x00000030) /*!< Verf_ADC connection bit */
#define SYSCFG_CFGR3_VREF_OUT_0 ((uint32_t)0x00000010) /*!< Bit 0 */
#define SYSCFG_CFGR3_VREF_OUT_1 ((uint32_t)0x00000020) /*!< Bit 1 */
#define SYSCFG_CFGR3_ENBUF_VREFINT_ADC ((uint32_t)0x00000100) /*!< VREFINT reference for ADC enable bit */
#define SYSCFG_CFGR3_ENBUF_SENSOR_ADC ((uint32_t)0x00000200) /*!< Sensor reference for ADC enable bit */
#define SYSCFG_CFGR3_ENBUFLP_VREFINT_COMP ((uint32_t)0x00001000) /*!< VREFINT reference for comparator 2 enable bit */
#define SYSCFG_CFGR3_SENSOR_ADC_RDYF ((uint32_t)0x08000000) /*!< Sensor for ADC ready flag */
#define SYSCFG_CFGR3_VREFINT_ADC_RDYF ((uint32_t)0x10000000) /*!< VREFINT for ADC ready flag */
#define SYSCFG_CFGR3_VREFINT_COMP_RDYF ((uint32_t)0x20000000) /*!< VREFINT for comparator ready flag */
#define SYSCFG_CFGR3_VREFINT_RDYF ((uint32_t)0x40000000) /*!< VREFINT ready flag */
#define SYSCFG_CFGR3_REF_LOCK ((uint32_t)0x80000000) /*!< CFGR3 lock bit */

[Nesrine M_O]

Posted on December 30, 2015 at 14:05

Hi horcicka.jan,

Thank you for your feedback. The issue has been reported internally.

  

-Syrine-

[jan]

Posted on December 30, 2015 at 14:52

Thank you very much for you response.

Could you please advise which is correct?

I'm trying to set up Vrefint for ADC correctly.

Kind regards,

Jan

[Nesrine M_O]

Posted on January 05, 2016 at 15:18

Hi horcicka.jan,

Sorry for the late response.

Your reported issue is confirmed by our team and will be fixed in coming release of the STM32cubeL0 package.

Thank you very much for your contribution to the enhancement of our STM32 related solutions.

-Syrine-

[re.wolff9]

Posted on January 05, 2016 at 18:54

Dear Syrine, 

Because the header file and the manual are not in agreement, we know one of them is wrong. 

Because you say it has been reported and will be fixed, we know that you agree. 

However what we would like to know is WHICH ONE IS CORRECT? Is the reference manual correct, or is the header file correct?

Or should we postpone our project for up to  six months waiting for a software/documentation update?

[Tesla DeLorean]

Posted on January 05, 2016 at 19:08

Well the double inference here is that a) the cube software is being fixed (ie it had the issue), and b) the OT complained that the current software wasn't working, where the usage diverged from the documentation.

You should validate the functionality of your product independently of what ST may or may not do, now or in the future. The license waives all this responsibility.

[Nesrine M_O]

Posted on January 06, 2016 at 10:06

Hi wolff.roger,

However what we would like to know is WHICH ONE IS CORRECT? Is the reference manual correct, or is the header file correct?

In fact the issue is on the HAL driver that it is not online with the reference manual update.

-Syrine-