stmicroelectronics / stm32f1xx_hal_driver

Provides the STM32Cube MCU Component "hal_driver" of the STM32F1 series.

STM32CubeF1 HAL Driver MCU Component

Overview

STM32Cube is an STMicroelectronics original initiative to ease the developers' life by reducing efforts, time and cost.

STM32Cube covers the overall STM32 products portfolio. It includes a comprehensive embedded software platform, delivered for each STM32 series.

• The CMSIS modules (core and device) corresponding to the ARM(tm) core implemented in this STM32 product.
• The STM32 HAL-LL drivers, an abstraction layer offering a set of APIs ensuring maximized portability across the STM32 portfolio.
• The BSP drivers of each evaluation, demonstration or nucleo board provided for this STM32 series.
• A consistent set of middleware libraries such as RTOS, USB, FatFS, graphics, touch sensing library...
• A full set of software projects (basic examples, applications, and demonstrations) for each board provided for this STM32 series.

Two models of publication are proposed for the STM32Cube embedded software:

• The monolithic MCU Package: all STM32Cube software modules of one STM32 series are present (Drivers, Middleware, Projects, Utilities) in the repository (usual name STM32Cubexx, xx corresponding to the STM32 series).
• The MCU component: each STM32Cube software module being part of the STM32Cube MCU Package, is delivered as an individual repository, allowing the user to select and get only the required software functions.

Description

This stm32f1xx_hal_driver MCU component repo is one element of the STM32CubeF1 MCU embedded software package, providing the HAL-LL Drivers part.

Release note

Details about the content of this release are available in the release note here.

Compatibility information

In this table, you can find the successive versions of this HAL-LL Driver component, in line with the corresponding versions of the full MCU package:

It is crucial that you use a consistent set of versions for the CMSIS Core - CMSIS Device - HAL, as mentioned in this table.

HAL Driver F1	CMSIS Device F1	CMSIS Core	Was delivered in the full MCU package
Tag v1.1.4	Tag v4.3.1	Tag v5.4.0_cm3	Tag v1.8.0 (and following, if any, till next HAL tag)
Tag v1.1.5	Tag v4.3.1	Tag v5.4.0_cm3	Tag v1.8.1 (and following, if any, till next HAL tag)
Tag v1.1.6	Tag v4.3.2	Tag v5.4.0_cm3	Tag v1.8.2 (and following, if any, till next HAL tag)
Tag v1.1.8	Tag v4.3.2	Tag v5.4.0_cm3	Tag v1.8.3 (and following, if any, till next HAL tag)
Tag v1.1.8	Tag v4.3.3	Tag v5.4.0_cm3	Tag v1.8.4 (and following, if any, till next HAL tag)

The full STM32CubeF1 MCU package is available here.

Troubleshooting

Please refer to the CONTRIBUTING.md guide.

stm32f1xx_hal_driver's Issues

Changing the write-only AFIO_MAPR.SWJ_CFG field in LL

In stm32f1xx_ll_gpio.h, LL_GPIO_AF_EnableRemap_SWJ(), LL_GPIO_AF_Remap_SWJ_NONJTRST, LL_GPIO_AF_Remap_SWJ_NOJTAG(), LL_GPIO_AF_DisableRemap_SWJ() all use

SET_BIT(AFIO->MAPR, AFIO_MAPR_SWJ_CFG_xxxxx);

which is incorrect, as SET_BIT is

#define SET_BIT(REG, BIT) ((REG) |= (BIT))

and the read value of AFIO_MAPR.SWJ_CFG field according to RM0008 is unpredictable.

This has been reported in https://community.st.com/t5/stm32-mcus-embedded-software/incorrectly-written-afio-mapr-swj-cfg-bits-in-cubef1-ll/m-p/90756 , can you please drop a comment there, too.

Thanks,

Jan Waclawek

Bug in HAL_FLASHEx_Erase_IT - if process already ongoing then pFlash remains locked

HAL_StatusTypeDef HAL_FLASHEx_Erase_IT(FLASH_EraseInitTypeDef *pEraseInit)
{
  HAL_StatusTypeDef status = HAL_OK;

  /* Process Locked */
  __HAL_LOCK(&pFlash);

  /* If procedure already ongoing, reject the next one */
  if (pFlash.ProcedureOnGoing != FLASH_PROC_NONE)
  {
>>> here must be  __HAL_UNLOCK(&pFlash); <<<<
    return HAL_ERROR;
  }

SetPinMode and SetPinPull sequence

Hello,
I switched to the latest cubef1 today. Unfortunately, the device stopped working :-(
I then found out that it had to do with these changes (stm32f1xx_ll_gpio.c):

old:

     /* Pin Mode configuration */
      LL_GPIO_SetPinMode(GPIOx, currentpin, GPIO_InitStruct->Mode);

      /* Pull-up Pull-down resistor configuration*/
      LL_GPIO_SetPinPull(GPIOx, currentpin, GPIO_InitStruct->Pull);

      if ((GPIO_InitStruct->Mode == LL_GPIO_MODE_OUTPUT) || (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE))
      {
        /* Check speed and Output mode parameters */
        assert_param(IS_LL_GPIO_SPEED(GPIO_InitStruct->Speed));
        assert_param(IS_LL_GPIO_OUTPUT_TYPE(GPIO_InitStruct->OutputType));

        /* Speed mode configuration */
        LL_GPIO_SetPinSpeed(GPIOx, currentpin, GPIO_InitStruct->Speed);

        /* Output mode configuration*/
        LL_GPIO_SetPinOutputType(GPIOx, currentpin, GPIO_InitStruct->OutputType);
      }

new:

      if ((GPIO_InitStruct->Mode == LL_GPIO_MODE_OUTPUT) || (GPIO_InitStruct->Mode == LL_GPIO_MODE_ALTERNATE))
      {
        /* Check speed and Output mode parameters */
        assert_param(IS_LL_GPIO_SPEED(GPIO_InitStruct->Speed));
        assert_param(IS_LL_GPIO_OUTPUT_TYPE(GPIO_InitStruct->OutputType));

        /* Speed mode configuration */
        LL_GPIO_SetPinSpeed(GPIOx, currentpin, GPIO_InitStruct->Speed);

        /* Output mode configuration*/
        LL_GPIO_SetPinOutputType(GPIOx, currentpin, GPIO_InitStruct->OutputType);
      }

      /* Pull-up Pull-down resistor configuration*/
      LL_GPIO_SetPinPull(GPIOx, currentpin, GPIO_InitStruct->Pull);

      /* Pin Mode configuration */
      LL_GPIO_SetPinMode(GPIOx, currentpin, GPIO_InitStruct->Mode);

Why was this changed? I didn´t found any issue for that in this repo. So i also found an issue here https://community.st.com/s/global-search/LL_GPIO_Init seems to be a little bit related. Can someone have a look on that?

many thanks

Interrupting USB Transfer

stm32f1xx_hal_driver/Inc/stm32f1xx_hal_pcd.h

Line 868 in ddf259a

*(pdwReg) &= 0x3FFU; \

This line of code is interrupting my USB Transfer in random time on STM32F103.
In Wireshark i see the OUT Endpoint answered with USBD_STATUS_STALL_PID

The host is continously sending Data to the OUT Pipe.
While debugging the HAL_PCD_EP_Receive , until this line of code, the connection is stable.
Stepping over it will interrupt the Transaction and on Host the Pipe is broken.

In normal running, the next line in Debug, will reactivate the Pipe to valid state, so the host is not recognizing it.
But some interrupts occour within this two lines and the transfer is broken.
The two lines are part of USB_EPStartXfer:

• 2441: PCD_SET_EP_RX_CNT(USBx, ep->num, len);
• 2467: PCD_SET_EP_RX_STATUS(USBx, ep->num, USB_EP_RX_VALID);

After deleting this line, i had no transfer interruptions any more.

STM32F1xx RTC BKP Registers 16bit, but HAL requests 32bits

I'm fairly new to MCU development and working with the STM32F1xx series, but I've been pointed over to here from the STM32duino project as they pull the HAL from here.

The RTC BKP registers on the STM32F103 (and I believe all of the STM32F1xx series) are 16bit, but the HAL driver (Inc/stm32f1xx_ll_rtc.h) requests and accepts an unsigned 32bit value. Of course it can't actually save 32bits only 16bits, so you lose the top 16bits of the data you sent.

Obviously it is possible to work around this by splitting the data over 2 registers, but is this by design? Perhaps there is an MCU in the series that has a 32bit backup register and I've missed it? In my opinion, if all MCUs in the series have 16bit RTC BKP registers, the HAL should request and accept just 16bits to avoid confusion and accidental data loss.

extern uwTick : Missing from F1 variant stm32f1xx_hal.h

Issue raised here STMicroelectronics/STM32CubeF1#12

Issue was first raised here stm32duino/Arduino_Core_STM32#1064

Describe the bug :

extern __IO uint32_t uwTick;

This declaration is missing from F1 variant, present on all other variants.

https://github.com/STMicroelectronics/STM32CubeF1/blob/5ddefcd6a64e793087436cc4ed42abd1886952c1/Drivers/STM32F1xx_HAL_Driver/Inc/stm32f1xx_hal.h#L59-L61

To Reproduce :

By inspection

See as example:
https://github.com/STMicroelectronics/STM32CubeF4/blob/5d01400afd60410f6e049cbd19179a67d44d53fd/Drivers/STM32F4xx_HAL_Driver/Inc/stm32f4xx_hal.h#L200-L207
and
https://github.com/STMicroelectronics/STM32CubeF7/blob/08376dce1b404687e4a86b73077f396bccfc9cb5/Drivers/STM32F7xx_HAL_Driver/Inc/stm32f7xx_hal.h#L195-L201

New release to STM32F1xxHAL

The last release / tag (v1.1.9) of STM32F1xxHAL library was in April last year, with several changes made since that time.
When is ST planning to produce a new tag?
My rationale for needing tagged versions is to aid traceability with regards to technical file review in regulated industry.

A bug when use HAL_UARTEx_ReceiveToIdle_DMA

Describe the bug
Cannot distinguish between half complete in DMA and idle interrupts

How To Reproduce

1. set a rxSize

2. use HAL_UARTEx_ReceiveToIdle_DMA

3. send half the data （rxSize/2）

4. HAL_UARTEx_RxEventCallback will be called 2 times with the same input parameter(size)