Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum

Describe the set-up

• Custom STM32G491 board.
• STM32CubeIDE 1.15.0 and STM32G4xx HAL Driver 1.2.3

Describe the bug
When I2C Speed is set to Fast Mode Plus AND Full Asserts are enabled the Driver always asserts.

How To Reproduce

1. Open ioc file

2. Activate checkbox "Enable Full Assert" under Project Manager -> Code Generator -> HAL Settings

3. Set I2C3 Speed Mode to "Fast Mode Plus" under "Pinout & Configuration" -> Connectivity -> I2C3 -> Parameter Settings -> Timing Configuration

4. Save ioc file and let generate code

5. Add a "while (1) {}" in the User Code section into the function assert_failed() in main.c

Additional context
The code generator adds the following line to MX_I2C3_Init() in i2c.c:
__HAL_SYSCFG_FASTMODEPLUS_ENABLE(I2C_FASTMODEPLUS_I2C3);

This macro is in stm32g4xx_hal.h and includes an assert that leads to:
assert_param(IS_SYSCFG_FASTMODEPLUS(I2C_FASTMODEPLUS_I2C3))

The problem is, that this macro checks for
I2C_FASTMODEPLUS_PB6, I2C_FASTMODEPLUS_PB7, I2C_FASTMODEPLUS_PB8, I2C_FASTMODEPLUS_PB9
but misses
I2C_FASTMODEPLUS_I2C1, I2C_FASTMODEPLUS_I2C2, I2C_FASTMODEPLUS_I2C3, I2C_FASTMODEPLUS_I2C4

A possible fix could be to change both macros __HAL_SYSCFG_FASTMODEPLUS_ENABLE and __HAL_SYSCFG_FASTMODEPLUS_DISABLE to use different asserts:
assert_param(IS_SYSCFG_FASTMODEPLUS((__FASTMODEPLUS__)) -> assert_param(IS_I2C_FASTMODEPLUS((__FASTMODEPLUS__))

Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• Custom STM32G431 board.
• STM32G4xx HAL Driver 1.5.2.

Describe the bug
A wrong behavior of subsequent HAL_FMAC_FilterStart() -> HAL_FMAC_FilterStop() -> HAL_FMAC_FilterStart().

How To Reproduce

1. FMAC is configured as FIR with output buffer access mode DMA.
2. The software periodically starts and stops FMAC, by calling HAL_FMAC_FilterStart() / HAL_FMAC_FilterStop().
3. The second call of HAL_FMAC_FilterStart() fails with DMA related HAL error.

Additional context
Follow the issue debugging, DMA transfer starts from within HAL_FMAC_FilterStart().
However, complementary DMA stop is missing in HAL_FMAC_FilterStop().

Describe the set-up

• STM32G491RE custom board
• STM32CubeIDE Version: 1.13.2 Build: 18220_20230914_1601 (UTC)

Describe the bug
When using the I2C hal driver with DMA the communication to an OLED display doesn't work. When using the I2C driver in IT mode the display works fine. The project firmware is found here https://github.com/olliw42/mLRS and the board schematics here https://github.com/olliw42/mLRS-hardware/tree/master/olliw-stm32-based/tx-module-02, if this should be of any help.

Tests have confirmed that the issue is specifically related to the I2C hal driver, that is, is located in the file stm32g4xx_hal_i2c.c

The board including OLED was working fine since ca 1.5 years, up to using commit @75ce54b. The issue appeared recently with upgrading to commit @74ce67c, and remains also after upgrading to the latest commit @7c2e15e. Downgrading back to @75ce54b resolves the issue.

Board: STM32G474RET6 or STM32G474RCT6
IDE/Compiler: [Keil µVision 5.36]

Issue Description
The STM32G4 series, specifically the STM32G474RET6 and STM32G474RCT6 chips, are designed to support firmware updates via serial communication by utilizing a dual BANK configuration. In this context, a mechanism to identify the current bank, write to the alternate bank, and subsequently switch between banks is crucial for seamless firmware updates.

For similar chip designs, such as the STM32F4 series, the HAL library provides the FLASH_OB_BootConfig function to facilitate this process. However, it appears that the STM32G4 HAL library lacks this essential functionality.

I think that the comment on these lines are actually inverted..

We are using an STM32G473VCT6 and the STM32 low level library (not the HAL) version 1.5.2.

The define LL_AHB2_GRP1_PERIPH_CCM in file stm32g4xx_ll_bus.h is invalid. If one uses it, one will get a compiler error.

The current define is the following:

#define LL_AHB2_GRP1_PERIPH_CCM RCC_AHB2SMENR_CCMSMEN

But the value RCC_AHB2SMENR_CCMSMEN is nowhere set. The most obvious fix for this controller would be:

#define LL_AHB2_GRP1_PERIPH_CCM RCC_AHB2SMENR_CCMSRAMSMEN

as RCC_AHB2SMENR_CCMSRAMSMEN is defined in file stm32g473xx.h.

The used toolchain is irrelevant to this failure, but we are using Visual Studio Code as IDE with (custom) CMake which uses gnu-tools-for-stm32 with gcc v11.3.

One can reproduce the compiler error if using the following line somewhere in the code:
LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_CCM);

Describe the set-up
HAL driver V1.2.2 / 10-November-2021 for STM32G4

Describe the bug
In stm32G4xx_hal_crs.h:
#define RCC_CRS_HSI48CALIBRATION_DEFAULT 0x00000020U
https://github.com/STMicroelectronics/stm32g4xx_hal_driver/blob/master/Inc/stm32g4xx_hal_rcc_ex.h#L518

In stm32G4xx_ll_crs.h:
#define LL_CRS_HSI48CALIBRATION_DEFAULT ((uint32_t)0x40U)

Both claim that:
The default value corresponds to the middle of the trimming interval.

In G4 the TRIM field of CRS_CR is 7 bits, so the right value is 0x40. The HAL value is wrong.

How To Reproduce
Look at the files

Additional context

Screenshots

Please add a LICENSE or LICENSE.md file as described in https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-license-to-a-repository

The struct member DataLength (found in multiple structs) has a misleading name and description.
It is neither data length in bytes nor a CAN Data Length Code (DLC). It is a shifted DLC value. No conversion function/macro is provided (DLCtoBytes is static).

https://github.com/STMicroelectronics/stm32g4xx_hal_driver/blob/fa6618be0a5b3b918bda9fbf990c70da966f7543/Src/stm32g4xx_hal_flash_ramfunc.c#L130C30-L130C56

status is set to HAL_ERROR on line 133. But it is never set to HAL_OK when succeeded, thus always returning HAL_ERROR

HAL_FDCAN_GetRxMessage doesn't check for buffer size. Since there is no function in this header file to request the size of the message before reading you are forced to allocate an array of 64 bytes to be sure. A bounds check would prevent buffer overflow and reading the size of the message before copying it would be helpful too,