stmicroelectronics / stm32cubel0 Goto Github PK

Was pyaling around with low poer modes on a STM32L071KZ and I did found out that both HAL_PWR_EnterSLEEPMode() and HAL_PWR_EnterSTOPMode() use what looks like to be a wrong WFI sequence.

The functions have the following code (which is not working, uC not going into Sleep/Stop mode)
if(STOPEntry == PWR_STOPENTRY_WFI) { /* Request Wait For Interrupt */ __WFI(); }

Changing to this code solved my issue:
if(STOPEntry == PWR_STOPENTRY_WFI) { /* Request Wait For Interrupt */ __DSB(); __WFI(); __ISB(); }

Similar to #17 , there are unnecessary duplicate volatile reads in the interrupt handler for the timer peripheral.
__HAL_TIM_GET_FLAG is called several times inside the handler, each time the actual value is fetched due to volatile qualifier.

As in #17, this likely affects all other device variants (F1/F3/F4...) as well.

The file USB_DEVICE/App/usbd_cdc_if.c in the stm32L0 HAL, as generated by CubeMX doesn't contain support registering a callback for USB transmit complete, whereas this functionality does exist in stm32L4, among other HALs. Instead of registering a callback, we're forced to call a function in the application main loop.

This is the function that is defined in L4 but not L0.

static int8_t CDC_TransmitCplt_FS(uint8_t *pbuf, uint32_t *Len, uint8_t epnum);

It looks like the lower level USB HAL supports this callback, and the L0 reference manual indicates the transmit complete interrupt is supported by the hardware. Curious as to why it is not supported in the USB_DEVICE layer.

Our team has considered adding this functionality to the usbd_cdc_if.c file, but would prefer not to maintain code instead of just using autogenerated CubeMX code.

Is this a feature that you could add to the stm32CubeL0 HAL? Or if our team created a pull request adding this feature would you consider adding?

Thanks.

Hello ST team,

The function LL_ADC_DMA_GetRegAddr contained in Drivers/STM32L0xx_HAL_Driver/Inc/stm32l0xx_ll_adc.h does not use the Register parameter, leading to warnings.

Please implement UNUSED(Register); to clear them :)

Best regards

Describe the set-up
Using arm-none-eabi-gcc and custom makefile project using an STM32L0 within a packaged muRata LoRa module on a custom board. Using the "-Wredundant-decls" flag.

Additional context
I believe the check and declaration in "stm32l0xx_hal_rcc_ex.c" lines 44-46 to be redundant, as PLLMulTable is declared in system_stm32l0xx.h example line 63 (it should exist in only one location). It doesn't appear to cause an issue (I haven't yet checked for duplicate objects in the build output) but produces a compiler warning, as it should. A different check may be more suitable.

Timers3 and 7 is not described in the stm32l051xx.h file even thought they are described in the reference guide for stmp32l051:

This is page 55 in RM0377 Rev 9 of the document.

The Period start value has changed from 0 to 1 in the macro IS_LPTIM_PERIOD(). In my opinion the lowest autoreload value should be 0.
I have tested a 1s period with the external LSE clock 32,768kHz and STM32L071CB: Timeout = 0x7FFF, due to processor errata = 0x7FFE, HAL_LPTIM_TimeOut_Start_IT(&lptimHandle, 1U, 0x7FFEU)). The LPTIM interrupt is raised every 999,95ms and before (with the HAL version 1.10.5) every 999,99ms (HAL_LPTIM_TimeOut_Start_IT(&lptimHandle, 0U, 0x7FFEU)).
Same issue is also in STM32CubeL4.

Similar to #17 , there are unnecessary duplicate volatile reads in the interrupt handler for the adc peripheral.
__HAL_ADC_GET_FLAG is called several times inside the handler, each time the actual value is fetched due to volatile qualifier.

As in #17, this likely affects all other device variants (F1/F3/F4...) as well. Interestingly, the implementation for the F4 variant actually caches the status register in a local variable, but does so multiple times, which defeats its purpose.

I wonder if it is possible to port this to a F411 board.
If so, must the SD card capacity be < 4GB as well?

Describe the set-up

• I'm using a custom board with an STM32L031F4Px
• IDE is stm32Cube Version 1.9.0
• My compiler is gcc-arm-none-eabi-10.3-2021.10

Describe the bug
Trying to respond to a read request from a master (configuring the STM32 as slave device) as per https://st.force.com/community/s/article/how-to-create-an-i2c-slave-device-using-the-stm32cube-library. This simply does not work, the only way to get it to work kind of is to reset the I2C peripheral in the transfer complete callback, but this results in loss of data.

Not sure how this is supposed to work, I have enabled interrupts and they are being triggered, but the problem is my SCL line goes down and does not recover. The address is correctly matched but I can't get any further:

How To Reproduce

1. Set-up the project as per https://st.force.com/community/s/article/how-to-create-an-i2c-slave-device-using-the-stm32cube-library.
2. Use the latest version of this repo as the HAL
3. The problem must be somewhere in the stm32l0xx_hal_i2c.c file
4. Use case is I2C slave device

Additional context
I do not have any proposal for a patch, trying to figure out how to resolve it but I don't fully understand the slave HAL.

The __HAL_TSC_GET_GROUP_STATUS macro is used to return the conversion status of an individual TSC group.

#define __HAL_TSC_GET_GROUP_STATUS(__HANDLE__, __GX_INDEX__) ...

The __GX_INDEX__ field is incorrectly masked in the #define definition resulting in the status being returned for TSC group 0 rather than the group requested by __GX_INDEX__.

This issue has previously been reported and acknowledged at https://community.st.com/s/question/0D50X0000ASrqJjSQJ/bug-in-stm32l0-tsc-library but a fix has not been made available in this repository.

When using this example on an STM32L071CB:

https://github.com/STMicroelectronics/STM32CubeL0/blob/master/Projects/NUCLEO-L073RZ/Examples/PWR/PWR_STOP/Src/system_stm32l0xx.c#L140-L141

I noticed that MCOSEL bits [2:0] are reset, but this register is actually 4 bits wide on STM32L0 and in order to disable MCO (I assume that is the intention), we need to reset all the bits.

Therefore I changed it to

RCC->CFGR &= (uint32_t) 0x80FF400CU;

Setup - custom PCB using STM32L011G4 micro.
IDE - 1.12.0
STM32CubeMX V6.8.0
STM32Cube FW_L0 V1.12.1

With latest upgrade using MX while I was changing size of the heap I was asked if I want to migrate the to latest STM32Cube firmware (6.8.0 I guess) and the code suddenly stopped working in debug. I found that it is forever locked in SystemClock_Config function in below line:

while (LL_PWR_IsActiveFlag_VOS() == 0)
{
}

I then checked that this line is not present if I re-generate the code using .ioc from previous commit which is using 6.7.0 version without migrating it.

I am using LL drivers for everything.

attached below is the the offending function generated by V6.8.0:

/**

• @brief System Clock Configuration
• @RetVal None
  */
  void SystemClock_Config(void)
  {
  LL_FLASH_SetLatency(LL_FLASH_LATENCY_1);
  while(LL_FLASH_GetLatency()!= LL_FLASH_LATENCY_1)
  {
  }
  LL_PWR_SetRegulVoltageScaling(LL_PWR_REGU_VOLTAGE_SCALE1);
  while (LL_PWR_IsActiveFlag_VOS() == 0)
  {
  }
  LL_RCC_HSI_Enable();

/* Wait till HSI is ready */
while(LL_RCC_HSI_IsReady() != 1)
{

}
LL_RCC_HSI_SetCalibTrimming(16);
LL_RCC_PLL_ConfigDomain_SYS(LL_RCC_PLLSOURCE_HSI, LL_RCC_PLL_MUL_4, LL_RCC_PLL_DIV_2);
LL_RCC_PLL_Enable();

/* Wait till PLL is ready */
while(LL_RCC_PLL_IsReady() != 1)
{

}
LL_RCC_SetAHBPrescaler(LL_RCC_SYSCLK_DIV_1);
LL_RCC_SetAPB1Prescaler(LL_RCC_APB1_DIV_1);
LL_RCC_SetAPB2Prescaler(LL_RCC_APB2_DIV_1);
LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);

/* Wait till System clock is ready */
while(LL_RCC_GetSysClkSource() != LL_RCC_SYS_CLKSOURCE_STATUS_PLL)
{

}

LL_Init1msTick(32000000);

LL_SetSystemCoreClock(32000000);
LL_RCC_SetLPUARTClockSource(LL_RCC_LPUART1_CLKSOURCE_PCLK1);
}

Hello,

I am writing a C++ wrapper on the top of ST's HAL and I have encountered a problem connected with interrupt callbacks and member functions.

Introduction

Registering interrupt callbacks is really cool thing in HAL, but it is not possible to assign a class member function as a callback function (it needs to be static). This problem is solved inside FreeRTOS, as it is possible to pass a user context to a task and then wrap handler function like this:

static void StaticThreadWrapper(void *parameter) {
            auto t = static_cast<ThreadController *>(parameter);
            t->ThreadTask();
}

Same thing is not possible inside HAL, but adding simple user context inside peripheral handler would fix the issue and make C++ developer's life easier.

Proposed solution

Add user context inside peripheral handlers (UART as example, but all other peripherals should be handled the same way).

void                          *pUserPtr;        /*!< Pointer to user context            */

After change:

/**
  * @brief  UART handle Structure definition
  */
typedef struct __UART_HandleTypeDef
{
  USART_TypeDef                 *Instance;        /*!< UART registers base address        */

  UART_InitTypeDef              Init;             /*!< UART communication parameters      */

  uint8_t                       *pTxBuffPtr;      /*!< Pointer to UART Tx transfer Buffer */

  uint16_t                      TxXferSize;       /*!< UART Tx Transfer size              */

  __IO uint16_t                 TxXferCount;      /*!< UART Tx Transfer Counter           */

  uint8_t                       *pRxBuffPtr;      /*!< Pointer to UART Rx transfer Buffer */

  uint16_t                      RxXferSize;       /*!< UART Rx Transfer size              */

  __IO uint16_t                 RxXferCount;      /*!< UART Rx Transfer Counter           */

  __IO HAL_UART_RxTypeTypeDef ReceptionType;      /*!< Type of ongoing reception          */

  DMA_HandleTypeDef             *hdmatx;          /*!< UART Tx DMA Handle parameters      */

  DMA_HandleTypeDef             *hdmarx;          /*!< UART Rx DMA Handle parameters      */

  HAL_LockTypeDef               Lock;             /*!< Locking object                     */

  __IO HAL_UART_StateTypeDef    gState;           /*!< UART state information related to global Handle management
                                                       and also related to Tx operations.
                                                       This parameter can be a value of @ref HAL_UART_StateTypeDef */

  __IO HAL_UART_StateTypeDef    RxState;          /*!< UART state information related to Rx operations.
                                                       This parameter can be a value of @ref HAL_UART_StateTypeDef */

  __IO uint32_t                 ErrorCode;        /*!< UART Error code                    */

  void                          *pUserPtr;        /*!< Pointer to user context            */ 

#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
  void (* TxHalfCpltCallback)(struct __UART_HandleTypeDef *huart);        /*!< UART Tx Half Complete Callback        */
  void (* TxCpltCallback)(struct __UART_HandleTypeDef *huart);            /*!< UART Tx Complete Callback             */
  void (* RxHalfCpltCallback)(struct __UART_HandleTypeDef *huart);        /*!< UART Rx Half Complete Callback        */
  void (* RxCpltCallback)(struct __UART_HandleTypeDef *huart);            /*!< UART Rx Complete Callback             */
  void (* ErrorCallback)(struct __UART_HandleTypeDef *huart);             /*!< UART Error Callback                   */
  void (* AbortCpltCallback)(struct __UART_HandleTypeDef *huart);         /*!< UART Abort Complete Callback          */
  void (* AbortTransmitCpltCallback)(struct __UART_HandleTypeDef *huart); /*!< UART Abort Transmit Complete Callback */
  void (* AbortReceiveCpltCallback)(struct __UART_HandleTypeDef *huart);  /*!< UART Abort Receive Complete Callback  */
  void (* WakeupCallback)(struct __UART_HandleTypeDef *huart);            /*!< UART Wakeup Callback                  */
  void (* RxEventCallback)(struct __UART_HandleTypeDef *huart, uint16_t Pos); /*!< UART Reception Event Callback     */

  void (* MspInitCallback)(struct __UART_HandleTypeDef *huart);           /*!< UART Msp Init callback                */
  void (* MspDeInitCallback)(struct __UART_HandleTypeDef *huart);         /*!< UART Msp DeInit callback              */
#endif  /* USE_HAL_UART_REGISTER_CALLBACKS */

} UART_HandleTypeDef;

Hi.

I'm using STM32L053R8T6 based custom PCB development board and testing USB custom HID.
the code

errno = USBD_CUSTOM_HID_SendReport(&hUsbDeviceFS, usb_send_data, sizeof(usb_send_data));

does not works and returned value errno is 1 which represents USBD_BUSY.
I used USB HID Demonstrator v1.0.2 tool to monitor it's communication status.

I solved this problem with simply downgrade firmware package version from 1.12.1 to 1.12.0 and it works as expected.
USBD_CUSTOM_HID_SendReport() function returns 0(USBD_OK)

Please check this issue.
Thanks.

Other repositories have been updated with HAL_TIM_DMABurst_MultiWriteStart and HAL_TIM_DMABurst_MultiReadStart. Is there any reason these functions can't be added for STM32CubeL0 also?

Hello,

for now, RxEventCallback does not allow to distinguish interrupt reason, in DMA mode this could be RX half transfer, RX transfer complete or RX line idle. Adding information about interrupt reason would allow end user to react only on certain situations, eg. RX line idle interrupt is really helpful in communication with GSM modems.

Proposed solution

Changes inside stm32l0xx_hal_uart.h contain adding meaningful information about DMA specific interrupts (not covered by UART status register) and extending RxEventCallback with interrupt reason.

/** @defgroup UART_RX_DMA_INTERRUPT_TYPE_Values  UART RX DMA interrupt type values
  * @{
  */
#define HAL_UART_RX_DMA_INTERRUPT_HALF_TRANSFER          (0xFFFFFFFEU)             /*!< RX DMA half transfer interrupt                       */
#define HAL_UART_RX_DMA_INTERRUPT_TRANSFER_COMPLETE      (0xFFFFFFFFU)             /*!< RX DMA transfer complete interrupt  */
/**
  * @}
  */

typedef  void (*pUART_RxEventCallbackTypeDef)(struct __UART_HandleTypeDef *huart, uint16_t Pos, uint32_t Interrupt);   /*!< pointer to a UART Rx Event specific callback function */

void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size, uint32_t Interrupt);

Changes inside stm32l0xx_hal_uart.c

void HAL_UART_IRQHandler(UART_HandleTypeDef *huart) 
{
...
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
        /*Call registered Rx Event callback*/
        huart->RxEventCallback(huart, (huart->RxXferSize - huart->RxXferCount), isrflags);
#else
        /*Call legacy weak Rx Event callback*/
        HAL_UARTEx_RxEventCallback(huart, (huart->RxXferSize - huart->RxXferCount), isrflags);
#endif
...
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
        /*Call registered Rx complete callback*/
        huart->RxEventCallback(huart, nb_rx_data, isrflags);
#else
        /*Call legacy weak Rx Event callback*/
        HAL_UARTEx_RxEventCallback(huart, nb_rx_data, isrflags);
#endif
}

__weak void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t Size, uint32_t Interrupt)
{
  /* Prevent unused argument(s) compilation warning */
  UNUSED(huart);
  UNUSED(Size);
  UNUSED(Interrupt);

  /* NOTE : This function should not be modified, when the callback is needed,
            the HAL_UARTEx_RxEventCallback can be implemented in the user file.
   */
}

static void UART_DMAReceiveCplt(DMA_HandleTypeDef *hdma)
{
...
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
    /*Call registered Rx Event callback*/
    huart->RxEventCallback(huart, huart->RxXferSize, HAL_UART_RX_DMA_INTERRUPT_TRANSFER_COMPLETE);
#else
    /*Call legacy weak Rx Event callback*/
    HAL_UARTEx_RxEventCallback(huart, huart->RxXferSize, HAL_UART_RX_DMA_INTERRUPT_TRANSFER_COMPLETE);
#endif /* USE_HAL_UART_REGISTER_CALLBACKS */
}

static void UART_DMARxHalfCplt(DMA_HandleTypeDef *hdma)
{
...
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
    /*Call registered Rx Event callback*/
    huart->RxEventCallback(huart, huart->RxXferSize/2U, HAL_UART_RX_DMA_INTERRUPT_HALF_TRANSFER);
#else
    /*Call legacy weak Rx Event callback*/
    HAL_UARTEx_RxEventCallback(huart, huart->RxXferSize/2U, HAL_UART_RX_DMA_INTERRUPT_HALF_TRANSFER);
#endif /* USE_HAL_UART_REGISTER_CALLBACKS */
}

static HAL_StatusTypeDef UART_Receive_IT(UART_HandleTypeDef *huart)
{
...
#if (USE_HAL_UART_REGISTER_CALLBACKS == 1)
        /*Call registered Rx Event callback*/
        huart->RxEventCallback(huart, huart->RxXferSize, isrflags);
#else
        /*Call legacy weak Rx Event callback*/
        HAL_UARTEx_RxEventCallback(huart, huart->RxXferSize, isrflags);
#endif
}

Rationale

Adding above changes will allow end user to distinguish various interrupt reasons, either by checking SR flags or checking predefined values for DMA interrupts.

HAL_MPU_ConfigRegion() is missing barrier instructions. (STM32CubeL0/Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_cortex.c)

The companion function, void HAL_MPU_Enable(uint32_t MPU_Control) Includes barrier instructions.

Per Arm Cortex-M0+ DevicesGeneric User Guide ( DUI0662B_cortex_m0p_r0p1_dgug.pdf), Section 4.5.8:

Software must use memory barrier instructions:

• Before MPU setup if there might be outstanding memory transfers, such as buffered writes, that might be affected by the change in MPU settings.
• After MPU setup, if the software includes memory transfers that must use the new MPU settings.

However, an instruction synchronization barrier instruction is not required if the MPU setup process starts by entering an exception handler, or is followed by an exception return, because the exception entry and exception return mechanisms cause memory barrier behavior.

For example, if you want all of the memory access behavior to take effect immediately after the programming sequence, use a DSB instruction and an ISB instruction. A DSB is required after changing MPU settings, such as at the end of context switch. An ISB is required if the code that programs the MPU region or regions is entered using a branch or call. If the programming sequence is entered using a return from exception, or by taking an exception, then you do not require an ISB.

If the Architecture of the L0 is such that that these barriers are not necessary or if the user is expected to supply them ( perhaps because they are being used within an ISR) that fact should be documented and/or clarified with expected usage samples.

In STM32CubeL0/Projects/32L0538DISCOVERY/Demonstrations/ there are only project files for EWARM and MDK-ARM, no STM32CubeIDE (ST) or SW4STM32 (ac6) or TrueSTUDIO (Atollic/ST)

.github/ISSUES/Templates, .github/ISSUES/Templates, .github/Pull Request template
CONTRIBUTING , CODE_OF_CONDUCT
Regards
Christophe

Hi all,
I had a problem with STM32CubeL0 about the crc routines.

Set-up

• Processor: STM32L051
• ST board: you can use any Nucleo/Discovery L0 board, as the problem is not related to the particular "external" hardware.
• Compiler: GCC 4.9.3 20141119, Linux host, ARM target

Description

• bad crc results when using "-O2" optimization.

How To Reproduce

1. Try a small crc calculation with CRC_INPUTDATA_FORMAT_BYTES or CRC_INPUTDATA_FORMAT_HALFWORDS : correct results with "-O0" optimization / bad results with "-O2" optimization.

2. The file: Drivers/STM32L0xx_HAL_Driver/Src/stm32l0xx_hal_crc.c - CRC_Handle_8 and CRC_Handle_16 routines

Explanation

compiler strict aliasing is enabled by "-O2" optimization. This is causing trouble.

Solution proposal

disable strict aliasing for these functions.

The functions become as follows:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstrict-aliasing"
static uint32_t attribute((optimize("no-strict-aliasing"))) CRC_Handle_8(CRC_HandleTypeDef *hcrc, uint8_t pBuffer[], uint32_t BufferLength) {
...[omissis]
}
static uint32_t attribute((optimize("no-strict-aliasing"))) CRC_Handle_16(CRC_HandleTypeDef *hcrc, uint16_t pBuffer[], uint32_t BufferLength) {
...[omissis]
}
#pragma GCC diagnostic pop

Comments

• The compiler version is rather old, but the issue seems related to strict-aliasing, so I am suspecting it is present also on other versions.
• The proposed solution obviously also needs an #ifdef __GNUC__ .

Conclusion

Using the corrections as exposed (no-strict-aliasing) the calculations are correct, my board is functioning correctly with "-O0" and with "-O2" compiler flags.
NOTE: I applied this patch also on other Cube libraries (example: L4), as the code is virtually the same.

Please, let me know your opinions.

Thanks,
best regards

Lucio Dona'

The mpu_arm7.h header shipped with the current version of the L0 (and possibly other) SDK has a bug that prevents the correct initialization of the MPU in a way that's hard to notice.
This commit shows that the problem with ARM_MPU_RASR_EX dropping important bits (it's missing the enable bit!) has been patched 5 years ago, I'd advise to backport this fix and/or update CMSIS as a whole.

Describe the set-up

• Custom Board with STM32L011F4 MCU
• uVision ARM-MDK 5.27.1.0

Describe the bug
When HSI with the HSI16DIV enabled is used as system clock, the function RCC_GetSystemClockFreq() returns the wrong frequency, because it only returns the define HSI_VALUE.
Because of this at least the LPUART baud is calculated wrong.

How To Reproduce
Setup HSI as system clock and enable the HSI16DIV Flag in the RCC->CR.

Additional context
In stm32l0xx_ll_rcc.c it should be:

case LL_RCC_SYS_CLKSOURCE_STATUS_HSI: /* HSI used as system clock source *'
{
if ((RCC->CR & RCC_CR_HSIDIVF) != 0)
{
sysclockfreq = (HSI_VALUE >> 2);
}
else
{
sysclockfreq = HSI_VALUE;
}
break;

The wrong behaviour seems to be in every RCC__GetFreq() function in the stm32l0xx_ll_rcc.c

It is correctly implemented in the stm32l0xx_hal_rcc.c

Screenshots
If applicable, add screenshots to help explain your problem.

When I use
__HAL_RTC_TAMPER_GET_IT()
with ARMCC5 I get a syntax error.

Please fix this.

I download the STM32CubeL0 V1.12.0
When I build stm32l0xx_hal_dac.c for STM32L052 with USE_HAL_DAC_REGISTER_CALLBACKS = 1 I get

stm32l0xx_hal_dac.c(296): error: #20: identifier "HAL_DACEx_ConvCpltCallbackCh2" is undefined
hdac->ConvCpltCallbackCh2 = HAL_DACEx_ConvCpltCallbackCh2;
stm32l0xx_hal_dac.c(297): error: #20: identifier "HAL_DACEx_ConvHalfCpltCallbackCh2" is undefined
hdac->ConvHalfCpltCallbackCh2 = HAL_DACEx_ConvHalfCpltCallbackCh2;
stm32l0xx_hal_dac.c(298): error: #20: identifier "HAL_DACEx_ErrorCallbackCh2" is undefined
hdac->ErrorCallbackCh2 = HAL_DACEx_ErrorCallbackCh2;
stm32l0xx_hal_dac.c(299): error: #20: identifier "HAL_DACEx_DMAUnderrunCallbackCh2" is undefined
hdac->DMAUnderrunCallbackCh2 = HAL_DACEx_DMAUnderrunCallbackCh2;
stm32l0xx_hal_dac.c(937): error: #20: identifier "HAL_DACEx_ConvCpltCallbackCh2" is undefined
hdac->ConvCpltCallbackCh2 = HAL_DACEx_ConvCpltCallbackCh2;
stm32l0xx_hal_dac.c(940): error: #20: identifier "HAL_DACEx_ConvHalfCpltCallbackCh2" is undefined
hdac->ConvHalfCpltCallbackCh2 = HAL_DACEx_ConvHalfCpltCallbackCh2;
stm32l0xx_hal_dac.c(943): error: #20: identifier "HAL_DACEx_ErrorCallbackCh2" is undefined
hdac->ErrorCallbackCh2 = HAL_DACEx_ErrorCallbackCh2;
stm32l0xx_hal_dac.c(946): error: #20: identifier "HAL_DACEx_DMAUnderrunCallbackCh2" is undefined
hdac->DMAUnderrunCallbackCh2 = HAL_DACEx_DMAUnderrunCallbackCh2;
stm32l0xx_hal_dac.c: 0 warnings, 8 errors

Please fix this ASAP with
#if defined (STM32L072xx) || defined (STM32L073xx) || defined (STM32L082xx) || defined (STM32L083xx)
#endif
like in stm32l0xx_hal_dac_ex.h
ReFe

The LL API seems to incorrectly assume that TS_CAL1 (temperature sensor calibration value @ 30c) is missing on the STM32L011 series.

The datasheet says in section 6.3.16 Temperature Sensor Characteristics, sub-point 2, "V30 ADC conversion result is stored in the TS_CAL1 byte".

I've tested this on STM32L011 development boards, and the TS_CAL1 value is indeed present in 0x1FF8007A, and the value seems sensible, producing quite accurate temperature readings using the included macro.

Could stm32l0xx_ll_adc.h be modified to correct this? Thanks.

In the STM32L0 example projects' system_stm32l0xx modules there is a reconfiguration of the RCC->CRRCR register in the default clock config, but only MCUs with an HSI48 include this register. For example, I was using this project with a STM32L071CB MCU which does not include the RCC->CRRCR register:

https://github.com/STMicroelectronics/STM32CubeL0/blob/master/Projects/NUCLEO-L073RZ/Examples/PWR/PWR_STOP/Src/system_stm32l0xx.c#L146-L147

I think it should be:

#if defined(RCC_HSI48_SUPPORT)
/*!< Reset HSI48ON  bit */
  RCC->CRRCR &= (uint32_t)0xFFFFFFFEU;
#endif

While this didn't appear to cause any problems for me, I was confused when using the example because I couldn't find this register in my MCU's reference manual. Hoping that it can help others who are going through the code line-by-line.