stmicroelectronics / stm32f2xx_hal_driver

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

STM32CubeF2 HAL Driver MCU Component

Overview

STM32Cube is an STMicroelectronics original initiative to ease 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 stm32f2xx_hal_driver MCU component repo is one element of the STM32CubeF2 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

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

The full STM32CubeF2 MCU package is available here.

Troubleshooting

If you have any issue with the software content of this repository, you can file an issue here.

For any other question related to the product, the tools, the environment, you can submit a topic on the ST Community/STM32 MCUs forum.

stm32f2xx_hal_driver's Issues

Signature for HAL_Delay in F2 produces a warning when compiled with C++20

The signature for HAL_Delay in the STM32f2xx_hal_driver is:

__weak void HAL_Delay(__IO uint32_t Delay)

This is different from the signatures for the other architectures I've checked (like H7, F7, F1 and G4) where the __IO part is removed (i.e. volatile).

The lack of consistency in the signature is far from ideal in it self, but it becomes an issue with C++ 20 where it produces the warning:

warning: 'volatile'-qualified parameter is deprecated [-Wvolatile]
(See: https://godbolt.org/z/3nnranYzq for an example)

I propose to make the signature the same as for the other architectures I've checked:

__weak void HAL_Delay(uint32_t Delay)

Constant interrupts during 2nd byte of 2 or 3 byte I2C receive.

STM32F205VBT6, stm32f2xx_hal_i2c.c: HAL_I2C_EV_IRQHandler and I2C_MasterReceive_RXNE

When receiving byte 2 out of a 2 or 3 byte receive using HAL_I2C_Master_Receive_IT, there is a storm interrupts. The following picture of of a series of transmissions with a slave. Green is SDA, yellow is SCL, and red is a GPIO set to high when HAL_I2C_EV_IRQHandler is called, and low when it returns. The second transmission is a 2 byte receive, with the interrupt storm highlighted. This is not from a minimal example, additional interrupts with higher priority are firing.

When starting the transmission, ITBUFEN is set, and hi2c->XferCount = 2/3. After the first byte is received, RXNE is set, generating an interrupt. HAL_I2C_EV_IRQHandler calls I2C_MasterReceive_RXNE. When the total tranmission is 2 or 3 bytes, this enters into the final, empty, else case and returns with no change. The flags are still set, and a new interrupt is generated. This continues until a second byte has been received, where BTF is set and I2C_MasterReceive_BTF is called instead of I2C_MasterReceive_RXNE. For a 2 byte receive, this is the end and the callback is called. For a 3 byte receive ITBUFEN is cleared and 1 byte read, preventing further interrupt spamming.

My suggested fix is to add __HAL_I2C_DISABLE_IT(hi2c, I2C_IT_BUF); to the final else in I2C_MasterReceive_RXNE. With that fix, only a single interrupt is generated for the second byte.

Error flag HAL_ADC_STATE_ERROR_INTERNAL checked but never set

Description
At line https://github.com/STMicroelectronics/stm32f2xx_hal_driver/blob/master/Src/stm32f2xx_hal_adc.c#L370 (just example) flag HAL_ADC_STATE_ERROR_INTERNAL checked

I looked in all the files and realized that it is not setting anywhere

Screenshots