stmicroelectronics/stm32cubeg4

STM32Cube MCU Full Package for the STM32G4 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))

STM32CubeG4 MCU Firmware Package

Important

This repository has been created using the git submodule command. Please refer to the "How to use" section for more details.

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.

The STM32CubeG4 MCU Package projects are directly running on the STM32G4 series boards. You can find in each Projects/Board name directories a set of software projects (Applications/Demonstration/Examples).

Release note

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

How to use

This repository has been created using the git submodule command. Please check the instructions below for proper use. Please check also the notes at the end of this section for further information.

1. To clone this repository along with the linked submodules, option --recursive has to be specified as shown below.

git clone --recursive https://github.com/STMicroelectronics/STM32CubeG4.git

2. To get the latest updates, in case this repository is already on your local machine, issue the following two commands (with this repository as the current working directory).

git pull
git submodule update --init --recursive

3. To use the same firmware version as the one available on st.com, issue the command below after specifying the targeted vX.Y.Z version. This should be done after the command(s) indicated in instruction (1) or in instruction (2) above have been successfully executed.

git checkout vX.Y.Z # Specify the targeted vX.Y.Z version

4. To avoid going through the above instructions and directly clone the same firmware version as the one available on st.com, issue the command below after specifying the targeted vX.Y.Z version.

git clone --recursive  --depth 1 --branch vX.Y.Z https://github.com/STMicroelectronics/STM32CubeG4.git

Note

• The latest version of this firmware available on GitHub may be ahead of the one available on st.com or via STM32CubeMX. This is due to the rolling release process deployed on GitHub. Please refer to this post for more details.
• Option --depth 1 specified in instruction (4) above is not mandatory. It may be useful to skip downloading all previous commits up to the one corresponding to the targeted version.
• If GitHub "Download ZIP" option is used instead of the git clone command, then the different submodules have to be collected and added manually.

Boards available

• STM32G4
  • STM32G474E-EVAL
  • NUCLEO-G431KB
  • NUCLEO-G431RB
  • NUCLEO-G474RE
  • B-G474E-DPOW1

Troubleshooting

Please refer to the CONTRIBUTING.md guide.

stm32cubeg4's Issues

[Feature Request] Pass arbitrary data pointer in callbacks

Feature Request
I very much appreciate the new callback functions added to the STM32Cube HAL, making it much easier to create our own middleware that integrates into the STM32Cube ecosystem. However there is still a limitation, the callbacks only provide pointers to their own handles.

For example, looking at the SPI callbacks:

https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Drivers/STM32G4xx_HAL_Driver/Inc/stm32g4xx_hal_spi.h#L150-L160

https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Drivers/STM32G4xx_HAL_Driver/Inc/stm32g4xx_hal_spi.h#L781

Lets say I am making a generic driver for some SPI device, which I want to scale to multiple SPI instances. With the callback API I can easily create a callback and register it to an STM32Cube driver. However inside of the callback context, the user only has access to the SPI handle assigned, with no way to know which user driver it came from without creating some global lookup.

Easy Solution

Either:

1. Allow passing a pointer which is stored with the callback:

HAL_StatusTypeDef HAL_SPI_RegisterCallback(SPI_HandleTypeDef *hspi, HAL_SPI_CallbackIDTypeDef CallbackID, pSPI_CallbackTypeDef pCallback, void* context);

2. Add a 'user pointer' field to the SPI_HandleTypeDef handle, so the user could say

hspi1->p_context = p_myDriverContext;

Flash latency inconsistency between STM32CubeG4 and RM0440

There is an inconsistency about between the flash latency in the LL_SetFlashLatency() function (file stm32g4xx_ll_utils.c) in STM32CubeG4 and the STM32 G4 Series Reference Manual. The configured wait states are for instance twice higher than in the reference manual for the maximum frequency of 170MHz. See:

• https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_utils.c#L226-L250
• https://www.st.com/resource/en/reference_manual/rm0440-stm32g4-series-advanced-armbased-32bit-mcus-stmicroelectronics.pdf pages 98, 150 and 191

Some RTC Macro did'nt use pHandle

The following RTC Macro didn't use HANDLE

G4

__HAL_RTC_WRITEPROTECTION_DISABLE( __HANDLE__);
__HAL_RTC_WRITEPROTECTION_ENABLE( __HANDLE__);
__HAL_RTC_ALARM_ENABLE_IT(__HANDLE__, RTC_IT_ALRA);
__HAL_RTC_ALARM_DISABLE_IT(__HANDLE__, RTC_IT_ALRA);
__HAL_RTC_ALARM_GET_IT_SOURCE(__HANDLE__, RTC_IT_ALRA)

__HAL_RTC_ALARMA_ENABLE( __HANDLE__);
__HAL_RTC_ALARMA_DISABLE( __HANDLE__);
__HAL_RTC_ALARMB_ENABLE( __HANDLE__);
__HAL_RTC_ALARMB_DISABLE( __HANDLE__);

__HAL_RTC_WAKEUPTIMER_ENABLE( __HANDLE__);
__HAL_RTC_WAKEUPTIMER_DISABLE( __HANDLE__);
__HAL_RTC_WAKEUPTIMER_CLEAR_FLAG(__HANDLE__, RTC_FLAG_WUTF);
__HAL_RTC_WAKEUPTIMER_ENABLE_IT(__HANDLE__, RTC_IT_WUT);
__HAL_RTC_WAKEUPTIMER_DISABLE_IT(__HANDLE__, RTC_IT_WUT);
__HAL_RTC_WAKEUPTIMER_GET_IT_SOURCE(__HANDLE__, RTC_IT_WUT)

__HAL_RTC_TIMESTAMP_ENABLE( __HANDLE__);
__HAL_RTC_TIMESTAMP_DISABLE( __HANDLE__);
__HAL_RTC_TIMESTAMP_CLEAR_FLAG(__HANDLE__, RTC_FLAG_WUTF);
__HAL_RTC_TIMESTAMP_ENABLE_IT(__HANDLE__, RTC_IT_TS);
__HAL_RTC_TIMESTAMP_DISABLE_IT(__HANDLE__, RTC_IT_TS);
__HAL_RTC_TIMESTAMP_GET_IT_SOURCE(__HANDLE__, RTC_IT_TS)
__HAL_RTC_TIMESTAMP_GET_IT(__HANDLE__, RTC_IT_WUT)

In other families HANDLE is required.
My compiler report warning: unused variable 'HANDLE' [-Wunused-variable]

example:
STM32G4:
#define __HAL_RTC_WRITEPROTECTION_ENABLE(HANDLE)
do{
RTC->WPR = 0xFFU;
} while(0)

STM32F4:
#define __HAL_RTC_WRITEPROTECTION_ENABLE(HANDLE)
do{
(HANDLE)->Instance->WPR = 0xFFU;
} while(0)
Please do it always the same way

BTW
Can you explain the do {...} while(0) ?
What is the the improvment to {...}

RetoFelix

STM32Cube_FW_G4_V1.1.0 HRTIM_Buck_Sync_Rect cannot not directly import

Hello,
Newbie here, I was trying to import HRTIM_Buck_Sync_Rect found in

STM32Cube_FW_G4_V1.1.0\Projects\B-G474E-DPOW1\Examples_MIX\HRTIM\

When I import the folder, I would need to generate code first, but will not be able to build.

So I go Project Manager >> Code Generator >> Copy only the necessary files from "Add necessary files ...."

Then generate code and I will be able to build but with errors on using LL functions and insert library and BSP codes.

I can see that in the HRTIM, the init was done using HAL but inside the HRTIM interrupt and Main funtions, LL was used.

Can HAL and LL of the same peripherals use both HAL and LL?
How to link the LL library in the project?
How to add link to BSP api and codes?
How to import the project files?

I am using STMCudeIDE 1.0.2 on windows 7. I tried on Linux, almost same errors can be seen.

LED not blinking on WUT RTC_ProgrammingTheWakeUpTimer

I tried the RTC_ProgrammingTheWakeUpTimer example. In the ReadMe it stated that:

• Launch the program (LED2 should toggle at each WUT (every 1 second))
  But in the Main loop there is just this:

    Process();
    LL_GPIO_TogglePin(LED2_GPIO_Port, LED2_Pin);
    LL_mDelay(1000);

So the LED2 is not blinking on WUT but just on a 1 sec Delay.

When I run this program the MCU never hits the void RTC_WKUP_IRQHandler(void)
Which it should do, based on the discription.

Can you please update the program so it works like it is mentiond in the Readme?

STM32CubeIDE Version: 1.9.0 Build: 12015_20220302_0855 (UTC)
NUCLEO-G431RB

HRTIM Fault Source Settings using LL Drivers

Describe the set-up

• STM32G474RE
• STMCubeIDE under Linux using the provided g++ toolchain

Describe the bug
The bug is in the low level driver for the HRTIM peripheral.
Setting the Fault Source Register using LL_HRTIM_FLT_SetSrc(...) uses a wrong mask
value to modify the contents of the second fault source register.
This results in previous settings to be overridden in the upper half of the register.
Please see file stm32g4xx_ll_hrtim.h, Line 9658 (or the previous mask generation statement).

How To Reproduce

1. Use the CubeMX Package to configure the HRTIM peripheral using multiple Fault Inputs with different fault sources.
   Especially Faults whose fault source bits are located in the upper half of the second fault source register (e.g. Fault4).
2. Run the generated code to just before LL_HRTIM_FLT_SetSrc(..) for the second configured channel(Fault5).
   The fault Source bits for Fault4 are set correctly.
3. Execute the second LL_HRTIM_FLT_SetSrc(..)
   This statement clears the upper half of the second fault source register -> Disables the fault4 source setting.

A patch would include a corrected Mask value for the second Fault Source Register.

UART baud rate is double when configuring PLLs using LL drivers on STM32G4xxx.

Describe the set-up

• NUCLEO_G474RE
• RTOS running is Zephyr
• The environment uses the Zephyr SDK for compiler, cmake / Ninja for build. all command line BASH.

Describe the bug
The function LL_PLL_ConfigSystemClock_HSI() in stm32g4xx_ll_utils.c temporarily divides the AHB clock by 2 if the SYSCLK divider is 1. According to the comments, this is to "Prevent undershoot at highest frequency by applying intermediate AHB prescaler 2".

The issue is that during this temporary AHB clock rate, the SystemCoreClock is updated to also be 1/2 the expected clock.

Although LL_PLL_ConfigSystemClock_HSI() resets the AHB clock properly, it does not reset the global variable SystemCoreClock.

This incorrect value is exposed when trying to set the UART baud rate later on in stm32g4xx_hal_uart.c.

Note that Zephyr uses the latest (0f8a4fd) with this recent pull-request integrated.

How To Reproduce

1. Configure SYSCLK to use the PLL. Divide it by 1 so it stays above 80MHz. Use LL_PLL_ConfigSystemClock_HSI() to configure PLLs using the pull-request mentioned above.
2. Use the UART HAL to configure an interface with baud rate 115200. Actual baud will be double.

See https://github.com/zephyrproject-rtos/zephyr/blob/master/drivers/clock_control/clock_stm32_ll_common.c#L346 for use of LL_PLL_ConfigSystemClock_HSI()

Additional context

This patch fixes the problem in my environment.

diff --git a/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_utils.c b/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_utils.c
index ea78949a..347d19b4 100644
--- a/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_utils.c
+++ b/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_utils.c
@@ -329,6 +329,7 @@ ErrorStatus LL_PLL_ConfigSystemClock_HSI(LL_UTILS_PLLInitTypeDef *UTILS_PLLInitS
     {
       UTILS_ClkInitStruct->AHBCLKDivider = LL_RCC_SYSCLK_DIV_1;
       LL_RCC_SetAHBPrescaler(UTILS_ClkInitStruct->AHBCLKDivider);
+      LL_SetSystemCoreClock(pllfreq);
     }
   }
   else
@@ -420,6 +421,7 @@ ErrorStatus LL_PLL_ConfigSystemClock_HSE(uint32_t HSEFrequency, uint32_t HSEBypa
     {
       UTILS_ClkInitStruct->AHBCLKDivider = LL_RCC_SYSCLK_DIV_1;
       LL_RCC_SetAHBPrescaler(UTILS_ClkInitStruct->AHBCLKDivider);
+      LL_SetSystemCoreClock(pllfreq);
     }
   }
   else

Screenshots
N/A

missing static const in static CRYP_AESGCM_Process_IT()

Hi
In the newest version of
static HAL_StatusTypeDef CRYP_AESGCM_Process_IT(CRYP_HandleTypeDef * const hcryp)
is a mask array

uint32_t mask[12U] = {0x0U, 0xFF000000UL, 0xFFFF0000UL, 0xFFFFFF00UL,  /* 32-bit data type */
                      0x0U, 0x0000FF00UL, 0x0000FFFFUL, 0xFF00FFFFUL,  /* 16-bit data type */
                      0x0U, 0x000000FFUL, 0x0000FFFFUL, 0x00FFFFFFUL}; /*  8-bit data type */

this should be static const.
Please fix this.

STM32G4 DMA DAC not working because of CubeMx code generation

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

• The board (either ST RPN reference or your custom board).
  STM32G491KEU6 on a custom board.

• IDE or at least the compiler and its version.
  STM32Cube v1.7.0

Describe the bug
CubeMx sometimes generates the function calls to MX_DAC1_Init(), MX_DMA_Init() in an order such that the DMA doesn't work. I experimentally found that MX_DAC1_Init() followed by MX_DMA_Init() doesn't work, whereas when they are called the other way around, it works.

How To Reproduce

1. Indicate the global behavior of your application project.

I use CubeMx to set DAC1_CH1 triggered by TIM6 and serviced by DMA1 channel 1.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

The CubeMx code generator.

3. The use case that generates the problem.

Servicing the DAC via DMA.

4. How we can reproduce the problem.

This archive STM32G4Cube-bug-report.zip contains two .ioc files and the two main.c files they generate. Both .ioc files set DAC1_CH1 triggered by TIM6 and serviced by DMA1 channel 1. However, they generate different code.
The salient difference between the two .ioc files is the order at these lines:

< ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_DAC1_Init-DAC1-false-HAL-true,4-MX_DMA_Init-DMA-false-HAL-true,5-MX_TIM6_Init-TIM6-false-HAL-true
---
> ProjectManager.functionlistsort=1-SystemClock_Config-RCC-false-HAL-false,2-MX_GPIO_Init-GPIO-false-HAL-true,3-MX_TIM2_Init-TIM2-false-HAL-true,4-MX_DMA_Init-DMA-false-HAL-true,5-MX_DAC1_Init-DAC1-false-HAL-true,6-MX_TIM6_Init-TIM6-false-HAL-true

As a result, they generate the following main() functions (from the respective main.c files:

main-Working.c:

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_DAC1_Init();
  MX_TIM6_Init();
  /* USER CODE BEGIN 2 */

main-NotWorking.c:

  /* USER CODE END SysInit */

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_DAC1_Init();
  MX_TIM6_Init();
  /* USER CODE BEGIN 2 */

(note the how MX_DMA_Init() and MX_DAC1_Init() are swapped in the two cases).
Now, with the minimal example code that follows (borrowed from here):

#define NS  128
    static uint32_t Wave_LUT[NS] = {
    2048, 2149, 2250, 2350, 2450, 2549, 2646, 2742, 2837, 2929, 3020, 3108, 3193, 3275, 3355,
    3431, 3504, 3574, 3639, 3701, 3759, 3812, 3861, 3906, 3946, 3982, 4013, 4039, 4060, 4076,
    4087, 4094, 4095, 4091, 4082, 4069, 4050, 4026, 3998, 3965, 3927, 3884, 3837, 3786, 3730,
    3671, 3607, 3539, 3468, 3394, 3316, 3235, 3151, 3064, 2975, 2883, 2790, 2695, 2598, 2500,
    2400, 2300, 2199, 2098, 1997, 1896, 1795, 1695, 1595, 1497, 1400, 1305, 1212, 1120, 1031,
    944, 860, 779, 701, 627, 556, 488, 424, 365, 309, 258, 211, 168, 130, 97,
    69, 45, 26, 13, 4, 0, 1, 8, 19, 35, 56, 82, 113, 149, 189,
    234, 283, 336, 394, 456, 521, 591, 664, 740, 820, 902, 987, 1075, 1166, 1258,
    1353, 1449, 1546, 1645, 1745, 1845, 1946, 2047
};
  HAL_DAC_Start_DMA(&hdac1, DAC_CHANNEL_1, (uint32_t*)Wave_LUT, NS, DAC_ALIGN_12B_R);
  HAL_TIM_Base_Start_IT(&htim6);

the Working example generates a tone, while the NotWorking example doesn't

Additional context

If you have a first analysis or patch correction, thank you to share your proposal.

I am not 100% the execution order of the two _Init() functions is supposed to matter. If it is supposed to matter, document it and fix the code generator. If it is not supposed to matter, fix the _Init() functions.

[LL_USART_Init] - bad assert_param for BRR register maximum value

STM32CubeG4/Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_usart.c

Line 303 in 3e5243a

assert_param(IS_LL_USART_BRR_MAX(USARTx->BRR));

this check here is too late and useless.
Because LL_USART_SetBaudrate called just above will never set BRR above 0xFFFF (as the higher bits are reserved) without any check if the calculation results in a higher result.

Obsolete type caddr_t

When building STM32CubeG4 examples using STM32CubeIDE Version 1.13.2, I get the following error:
'unknown type name 'caddr_t' ' in [example]/STM32CubeIDE/Application/User/sysmem.c:63:1

Including <sys/types.h> fixes the error. However, caddr_t is an obsolete typedef. It's recommended to replace these with void*.

__PKHBT and __PKHTB are STILL wrong

As you can see here:

STM32CubeG4/Drivers/CMSIS/Include/cmsis_gcc.h

Lines 2129 to 2152 in 29e23e9

	#if 0
	#define __PKHBT(ARG1,ARG2,ARG3) \
	({ \
	uint32_t __RES, __ARG1 = (ARG1), __ARG2 = (ARG2); \
	__ASM ("pkhbt %0, %1, %2, lsl %3" : "=r" (__RES) : "r" (__ARG1), "r" (__ARG2), "I" (ARG3) ); \
	__RES; \
	})
	#define __PKHTB(ARG1,ARG2,ARG3) \
	({ \
	uint32_t __RES, __ARG1 = (ARG1), __ARG2 = (ARG2); \
	if (ARG3 == 0) \
	__ASM ("pkhtb %0, %1, %2" : "=r" (__RES) : "r" (__ARG1), "r" (__ARG2) ); \
	else \
	__ASM ("pkhtb %0, %1, %2, asr %3" : "=r" (__RES) : "r" (__ARG1), "r" (__ARG2), "I" (ARG3) ); \
	__RES; \
	})
	#endif
	#define __PKHBT(ARG1,ARG2,ARG3) ( ((((uint32_t)(ARG1)) ) & 0x0000FFFFUL) | \
	((((uint32_t)(ARG2)) << (ARG3)) & 0xFFFF0000UL) )
	#define __PKHTB(ARG1,ARG2,ARG3) ( ((((uint32_t)(ARG1)) ) & 0xFFFF0000UL) | \
	((((uint32_t)(ARG2)) >> (ARG3)) & 0x0000FFFFUL) )

The version in this repository is STILL incorrect, and should be fixed please. Here is the CMSIS version:
https://github.com/ARM-software/CMSIS_5/blob/a75f01746df18bb5b929dfb8dc6c9407fac3a0f3/CMSIS/Core/Include/cmsis_gcc.h#L2183-L2200

I reported this months ago and you closed my PR since you said it didn't match the CMSIS version, but clearly it does: #39

Here is the commit change where they changed this: ARM-software/CMSIS_5@8a1fd91

FDCAN Timeout after a long (days) run.

Describe the set-up

• Custom board based on STM32G431
• GNU arm-none-eabi 7-2018-q2-update

Describe the bug
FDCAN Timeout after a long (days) run.

How To Reproduce

1. Indicate the global behavior of your application project.
   No FDCAN Timeout

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).
   FDCAN driver (stm32g4xx_hal_fdcan.c)

3. The use case that generates the problem.
   Long (days) run.

Additional context
In this piece of code if tickstart is 0xFFFFFFFF and a Tick ISR occur in the middle and so the next call to HAL_GetTick() returns 0 the resulting timeout check return a timeout event.

  tickstart = HAL_GetTick();

  /* Check Sleep mode acknowledge */
  while ((hfdcan->Instance->CCCR & FDCAN_CCCR_CSA) == FDCAN_CCCR_CSA)
  {
    if ((HAL_GetTick() - tickstart) > FDCAN_TIMEOUT_VALUE)

Doubled activation of TRGO in ADC example

There are two calls in a row of a function LL_TIM_SetTriggerOutput. Otherwise may be I'v misunderstood the idea.

conversion warnings for __NVIC_SetVector and __NVIC_GetVector

Describe the set-up

• MCU: STM32G474VETx
• IDE: STM32CubeIDE
• Libraries: Using the same library files provided in this repository

*Problem Description:

• Objective: Activate the -Werror flag for the entire project.
• Encountered Errors: Receiving errors due to conversion warnings from functions in core_cm4.h, specifically the functions __NVIC_SetVector (line 1905) and __NVIC_GetVector (line 1921).
• Error Details:

Conversion Warning:
Error Message: conversion to 'int' from 'uint32_t' {aka 'long unsigned int'} may change the sign of the result [-Werror=sign-conversion]
File: core_cm4.h
Path: /Drivers/CMSIS/Include
Line: 1908
Type: C/C++ Problem

Sign-Conversion Warning:
Error Message: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Werror=sign-conversion]
File: core_cm4.h
Path: /Drivers/CMSIS/Include
Line: 1908
Type: C/C++ Problem

Sign-Conversion Warning:
Error Message: conversion to 'long unsigned int' from 'long int' may change the sign of the result [-Werror=sign-conversion]
File: core_cm4.h
Path: /DCDC_MCU/Drivers/CMSIS/Include
Line: 1924
Type: C/C++ Problem

Additional context
This can be ommitted by using #pragma

LL SPI_TwoBoards_FullDuplex_DMA_Master_Init examples

In SPI_TwoBoards_FullDuplex_DMA_Master_Init examples
SPI1_RX is connected to DMA1_Channel1 and SPI1_TX is connected to DMA1_Channel3,
but in code DMA channel 3 is reporting DMA1_ReceiveComplete_Callback and DMA channel 1 DMA1_TransmitComplete_Callback.

The same here:
LL_DMA_SetDataLength(DMA1, LL_DMA_CHANNEL_3, ubNbDataToReceive);
LL_DMA_SetDataLength(DMA1, LL_DMA_CHANNEL_1, ubNbDataToTransmit);

To set transmit size we use ubNbDataToReceive and to receive ubNbDataToTransmit.

Examples are executing ok but naming is at least confusing.

Missing package definitions

In file stm32g4xx_ll_utils.h the package type list should be fixed:

/** @defgroup UTILS_EC_PACKAGETYPE PACKAGE TYPE
  * @{
  */
#define LL_UTILS_PACKAGETYPE_LQFP64         0x00000000U /*!< LQFP64 package type                      */
#define LL_UTILS_PACKAGETYPE_LQFP80 <-- MISSING !!!
#define LL_UTILS_PACKAGETYPE_LQFP100        0x00000002U /*!< LQFP100 package type                     */
#define LL_UTILS_PACKAGETYPE_WLCSP81        0x00000005U /*!< WLCSP81 package type                     */
#define LL_UTILS_PACKAGETYPE_LQFP128        0x00000007U /*!< LQFP128 package type                     */
#define LL_UTILS_PACKAGETYPE_UFQFPN32       0x00000008U /*!< UFQFPN32 package type                    */
#define LL_UTILS_PACKAGETYPE_LQFP32         0x00000009U /*!< LQFP32 package type                      */
#define LL_UTILS_PACKAGETYPE_UFQFPN48       0x0000000AU /*!< UFQFPN48 package type                    */
#define LL_UTILS_PACKAGETYPE_LQFP48         0x0000000BU /*!< LQFP48 package type                      */
#define LL_UTILS_PACKAGETYPE_WLCSP49        0x0000000CU /*!< WLCSP49 package type                     */
#define LL_UTILS_PACKAGETYPE_UFBGA64        0x0000000DU /*!< UFBGA64 package type                     */
#define LL_UTILS_PACKAGETYPE_UFBGA100 <-- not exists... TFBG100 maybe?
#define LL_UTILS_PACKAGETYPE_UFBGA121 <-- MISSING !!!
#define LL_UTILS_PACKAGETYPE_LQFP48_EBIKE   0x00000010U /*!< LQFP48 EBIKE package type                */

Release note issue ?

Hi,

in the release note of the CubeG4 v1.2.0, it is mentioned:

STM32CubeG4/Release_Notes.html

Lines 133 to 137 in 21b2f2f

	<li>Update HAL I2C processes to report ErrorCode when wrong I2C start condition occurs
	<ul>
	<li>Add new ErrorCode define: HAL_I2C_WRONG_START</li>
	<li>Set ErrorCode parameter in I2C handle to HAL_I2C_WRONG_START</li>
	</ul></li>

But I could not find any code related to HAL_I2C_WRONG_START?

Same in the G4 HAL drivers release 1.1.1:
https://github.com/STMicroelectronics/stm32g4xx_hal_driver/blob/be4da93755336778a77b65ae5d85e97070b82750/Release_Notes.html#L118-L122

Unable to compile USB PD middleware with USBCORE_VPD config

Describe the set-up

• STM32G474-EVAL hardware
• Projects/STM32G474E-EVAL/Demonstrations/Modules/ucpd/ project with -DUSBCORE_VPD=1 defined on gcc command line.
• stm32cube IDE
• Project using USBPDCORE_PD3_FULL_CM4_wc32.a

Describe the bug
Besides a few compile errors with the source code, there's a linker error for USBPD_PE_StateMachine_SNKwVPD() implementation. This should be included in the library, but the linker cannot find it.

How To Reproduce
Compile Projects/STM32G474E-EVAL/Demonstrations/Modules/ucpd/ with -DUSBCORE_VPD=1 to enable the VPD code.

Additional context
USBCORE_VPD is not defined anywhere in usbpd_def.h. Does this mean the STCube library does not support VPD / VPA as defined in the USB PD specification?

FDCAN RxHeader member IsFilterMatchingFrame and FilterIndex lacking documentation

Description

The FDCAN_RxHeaderTypeDef member IsFilterMatchingFrame and FilterIndex naming and documentation are confusing and do not convey the behavior when a non matching frame is received.

  uint32_t FilterIndex;           /*!< Specifies the index of matching Rx acceptance filter element.
                                       This parameter must be a number between:
                                        - 0 and (SRAMCAN_FLS_NBR-1), if IdType is FDCAN_STANDARD_ID
                                        - 0 and (SRAMCAN_FLE_NBR-1), if IdType is FDCAN_EXTENDED_ID */

  uint32_t IsFilterMatchingFrame; /*!< Specifies whether the accepted frame did not match any Rx filter.
                                         Acceptance of non-matching frames may be enabled via
                                         HAL_FDCAN_ConfigGlobalFilter().
                                         This parameter can be 0 or 1                                    */

https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Drivers/STM32G4xx_HAL_Driver/Inc/stm32g4xx_hal_fdcan.h#L231-L239

Expected Behavior

Based on the description of these two elements, I would expect FilterIndex to always be between 0 and (SRAMCAN_FLE_NBR-1) for extended frames (i.e. between 0 and 8).

The naming of IsFilterMatchingFrame would make be think that a value of 0 means that the frame did not match a filter. Reading the documentation for this element is a bit ambiguous (the description is opposite of the variable name).

Actual Behavior

When a filter is matched, FilterIndex is set to the filter number as expected, but IsFilterMatchingFrame is set to 0.

When a filter is not matched, FilterIndex is set to 63, which is not documented here, and IsFilterMatchingFrame is set to 1.

Fix

It is probably well too late to change the name or value of IsFilterMatchingFrame, so updating the documentation to be more clear would be the only fix. Something like:

  uint32_t FilterIndex;           /*!< Specifies the index of matching Rx acceptance filter element.
                                       This parameter must be a number between:
                                        - 0 and (SRAMCAN_FLS_NBR-1), if IdType is FDCAN_STANDARD_ID
                                        - 0 and (SRAMCAN_FLE_NBR-1), if IdType is FDCAN_EXTENDED_ID 

                                       When the frame is a Non-Filter matching frame, the value will be <xx>*/

  uint32_t IsFilterMatchingFrame; /*!< Specifies whether the accepted frame did not match any Rx filter.
                                         Acceptance of non-matching frames may be enabled via
                                         HAL_FDCAN_ConfigGlobalFilter().
                                         This parameter will be 0 if the frame matched an Rx filter or 1 if it did not match any Rx filter                                   */

ADC2 not properly initialized in LL mode

Describe the set-up

STM32CubeIDE Version: 1.4.2
FW_G4 V1.3.0
mcu: STM32G474RETx
STM32CubeMX Version: 6.0.1-RC3 Build: 20200810-1643 (UTC)

Describe the bug
In initialization of ADC2 in LL mode some functions are referencing ADC1:

/* Disable ADC deep power down (enabled by default after reset state) /
LL_ADC_DisableDeepPowerDown(ADC1);
/ Enable ADC internal voltage regulator */
LL_ADC_EnableInternalRegulator(ADC1);

generated init function:

/* ADC2 init function */
void MX_ADC2_Init(void)
{
  LL_ADC_InitTypeDef ADC_InitStruct = {0};
  LL_ADC_REG_InitTypeDef ADC_REG_InitStruct = {0};
  LL_ADC_CommonInitTypeDef ADC_CommonInitStruct = {0};

  LL_GPIO_InitTypeDef GPIO_InitStruct = {0};

  /* Peripheral clock enable */
  LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_ADC12);

  LL_AHB2_GRP1_EnableClock(LL_AHB2_GRP1_PERIPH_GPIOA);
  /**ADC2 GPIO Configuration
  PA0   ------> ADC2_IN1
  PA1   ------> ADC2_IN2
  */
  GPIO_InitStruct.Pin = LL_GPIO_PIN_0;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ANALOG;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  GPIO_InitStruct.Pin = LL_GPIO_PIN_1;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ANALOG;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_NO;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

  /** Common config
  */
  ADC_InitStruct.Resolution = LL_ADC_RESOLUTION_12B;
  ADC_InitStruct.DataAlignment = LL_ADC_DATA_ALIGN_RIGHT;
  ADC_InitStruct.LowPowerMode = LL_ADC_LP_MODE_NONE;
  LL_ADC_Init(ADC2, &ADC_InitStruct);
  ADC_REG_InitStruct.TriggerSource = LL_ADC_REG_TRIG_SOFTWARE;
  ADC_REG_InitStruct.SequencerLength = LL_ADC_REG_SEQ_SCAN_DISABLE;
  ADC_REG_InitStruct.SequencerDiscont = LL_ADC_REG_SEQ_DISCONT_DISABLE;
  ADC_REG_InitStruct.ContinuousMode = LL_ADC_REG_CONV_SINGLE;
  ADC_REG_InitStruct.DMATransfer = LL_ADC_REG_DMA_TRANSFER_NONE;
  ADC_REG_InitStruct.Overrun = LL_ADC_REG_OVR_DATA_PRESERVED;
  LL_ADC_REG_Init(ADC2, &ADC_REG_InitStruct);
  LL_ADC_SetGainCompensation(ADC2, 0);
  LL_ADC_SetOverSamplingScope(ADC2, LL_ADC_OVS_DISABLE);

  /* Disable ADC deep power down (enabled by default after reset state) */
  LL_ADC_DisableDeepPowerDown(ADC1);
  /* Enable ADC internal voltage regulator */
  LL_ADC_EnableInternalRegulator(ADC1);
  /* Delay for ADC internal voltage regulator stabilization. */
  /* Compute number of CPU cycles to wait for, from delay in us. */
  /* Note: Variable divided by 2 to compensate partially */
  /* CPU processing cycles (depends on compilation optimization). */
  /* Note: If system core clock frequency is below 200kHz, wait time */
  /* is only a few CPU processing cycles. */
  uint32_t wait_loop_index;
  wait_loop_index = ((LL_ADC_DELAY_INTERNAL_REGUL_STAB_US * (SystemCoreClock / (100000 * 2))) / 10);
  while(wait_loop_index != 0)
  {
    wait_loop_index--;
  }
  ADC_CommonInitStruct.CommonClock = LL_ADC_CLOCK_SYNC_PCLK_DIV4;
  LL_ADC_CommonInit(__LL_ADC_COMMON_INSTANCE(ADC2), &ADC_CommonInitStruct);
  /** Configure Regular Channel
  */
  LL_ADC_REG_SetSequencerRanks(ADC2, LL_ADC_REG_RANK_1, LL_ADC_CHANNEL_1);
  LL_ADC_SetChannelSamplingTime(ADC2, LL_ADC_CHANNEL_1, LL_ADC_SAMPLINGTIME_2CYCLES_5);
  LL_ADC_SetChannelSingleDiff(ADC2, LL_ADC_CHANNEL_1, LL_ADC_DIFFERENTIAL_ENDED);

}

How To Reproduce
Generate project and enable ADC2 in LL mode.

IS_OPAMP_POWERMODE() use legacy OPAMP_POWERMODE_NORMAL

I download STM32CubeG4 V1.4.0

In stm32g4xx_hal_opamp.h is in IS_OPAMP_POWERMODE() the legacy value OPAMP_POWERMODE_NORMAL used.

#define IS_OPAMP_POWERMODE(POWERMODE) (((POWERMODE) == OPAMP_POWERMODE_NORMAL) || \
                                       ((POWERMODE) == OPAMP_POWERMODE_HIGHSPEED) )

But the current value are:

#define OPAMP_POWERMODE_NORMALSPEED   (0x00000000UL)         /*!< Output in normal mode */
#define OPAMP_POWERMODE_HIGHSPEED     OPAMP_CSR_HIGHSPEEDEN  /*!< Output in highspeed mode */

Please fix this ASAP
ReFe

Why PDM2PCM is not added in G4?

I added manually PDM2PCM in G4, so far it is working.
Why is it not added in G4?
I tried to ask in the community https://community.st.com/s/question/0D53W00001TGJ2wSAH/why-is-pdm2pcm-not-enabled-for-stm32g4-in-cubemx

CMSIS DSP Library Not Updated

Just a basic request. Noticed the DSP library included with the firmware haven't been updated in over 4 years, and there are many new updated functions available in the newer releases.

Thank you.

PLLVCO_INPUT_MAX does not match with datasheet

The value UTILS_PLLVCO_INPUT_MAX is defined as 8MHz in this library.

However the datasheet, on page 108, suggests a value of 16MHz.

G491 and G4A1 wrong RAM size in linker script

In the linker scripts for G491 and G4A1 the RAM size seems to be 128kB but on G4 series web page statement is 112kB. One of the two is false.

NUCLEO-G431RB/Examples/PWR/PWR_SHUTDOWN doesn't work

Describe the set-up

• Using Nucleoboard NUCLEO-G431RB
• IAR Embedded Workbench 8.4, IAR Compiler 8.4

Describe the bug
Compiling and downloading this example, the controller won't go to the shutdown mode. After pressing User Button, the controller starts up again. Using ST-Link, in Shutdown mode it must loose connection to target, but debugging runs.

How To Reproduce

1. Compiling and download software from NUCLEO-G431RB/Examples/PWR/PWR_SHUTDOWN
2. Press user button
3. Controller doen't shut down like described in readme.txt

EXTI_ToggleLedOnIT and EXTI_ToggleLedOnIT_Init are totally the same

Documentation issues:

1. EXTI_ToggleLedOnIT and EXTI_ToggleLedOnIT_Init are totally the same, both main.c and ioc files
2. It mentions in the readme file that it is triggered at the falling edge but it should be rising edge as shown in its SCH.
   
3. The ioc files labels PC4 as USER_BUTTON, while it should be PC13
   
4. PC4 is not used and can be Reset_State, it is here that the external trigger is falling edge.

Feature request: HRTIM add option to disable fault blanking window

As of STM32CubeG4 v1.3.0 it is not possible to generate the HRTIM fault lines initialization code without it also calling to HAL_HRTIM_FaultBlankingConfigAndEnable(). Please add the option for the blanking window to be either disabled or enabled to the Fault Lines Configuration window in CubeMX.

HAL_FMAC_FilterStop does not terminate DMA transfer

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().

FDCAN DataLength Field Clarification/Usability

Describe the set-up
My application is using STM32G4 series, with FDCAN in Classic Mode. We have other devices that use STM32Fxxx with bxCAN, and are building a compatibility layer.

While looking through the documentation for configuring the DLC, it is surprising to find that the DLC is forced to be a define of 'type' FDCAN_data_length_code' which is equivalent to using DLC << 16. I understand that this is used later to 'or' with the TX RAM field, however it is already shifted back once to back-calculate the number of bytes to copy when calling HAL_FDCAN_AddMessageToTxFifoQ or when receiving.

Since the shift is already being done internal to the HAL driver, wouldn't it make sense to shift left internally, instead of making the interface confusing to the user? The driver can still check that it is a valid DLC, and keep the same defined values.

https://github.com/STMicroelectronics/STM32CubeG4/blob/master/Drivers/STM32G4xx_HAL_Driver/Inc/stm32g4xx_hal_fdcan.h#L604-L619

TIM_InputCapture HAL Example uwDiffCapture always the same value when changing APB2 prescaler

Hello Newbie here.
I was testing HAL example "TIM_InputCapture" using TIM1.
To get the value of input freq, it uses this formula:

uwFrequency = HAL_RCC_GetPCLK2Freq() / uwDiffCapture;

As I was changing the APB2 Prescaler in CubeMX, the value uwDiffCapture still remains the same.
That means, uwFrequency will change because HAL_RCC_GetPCLK2Freq() changes.
I also add this to check the new APB2 freq as I change it in CubeMX:

PCLK2Freq = HAL_RCC_GetPCLK2Freq();

Should it be using APB1 freq instead for TIM1?

UTILS_ConfigureSystemClock example not functioning correctly

Describe the set-up

• Board: NUCLEO-G431RB
• STM32CubeG4: v1.2.0
• Compiler and its version: arm-none-eabi-gcc (xPack GNU Arm Embedded GCC, 32-bit) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

Describe the bug
The UTILS_ConfigureSystemClock example for the NUCLEO-G431RB which can be found here doesn't function correctly.

There are two problems.

Problem 1

When the example runs, LL_PLL_ConfigSystemClock_HSI which is called here returns ERROR. It returns ERROR because the PLL is enabled when LL_PLL_ConfigSystemClock_HSI is called. In order for LL_PLL_ConfigSystemClock_HSI to function correctly, the application must ensure that the PLL is disabled. The PLL was enabled by calling SystemClock_Config directly before calling LL_PLL_ConfigSystemClock_HSI.

To workaround this problem the call to SystemClock_Config can be commented out as it's not actually needed here. However, this leads to the second problem.

Problem 2

After commenting out the call to SystemClock_Config, the call to LL_PLL_ConfigSystemClock_HSI hangs and never returns. This occurs because the data passed to LL_PLL_ConfigSystemClock_HSI in sUTILS_PLLInitStruct is incorrect. Currently, sUTILS_PLLInitStruct is initialized as follows which is incorrect:

/* Variable to store PLL parameters */
/* Configuration will allow to reach a SYSCLK frequency set to 170MHz:
   Syst freq = ((HSI_VALUE / PLLM) * PLLN)/ PLLP)
               ((16MHz /4) * 85)/ 2)             = 170MHz             */
LL_UTILS_PLLInitTypeDef sUTILS_PLLInitStruct = {LL_RCC_PLLM_DIV_4, 85, LL_RCC_PLLP_DIV_2};

Here is how sUTILS_PLLInitStruct should be initialized:

/* Variable to store PLL parameters */
/* Configuration will allow to reach a SYSCLK frequency set to 170MHz:
   Syst freq = ((HSI_VALUE / PLLM) * PLLN)/ PLLR)
               ((16MHz /4) * 85)/ 2)             = 170MHz             */
LL_UTILS_PLLInitTypeDef sUTILS_PLLInitStruct = {LL_RCC_PLLM_DIV_4, 85, LL_RCC_PLLR_DIV_2};

Notice how PLLP has been replaced with PLLR in both the comment and the code.

A similar example for the NUCLEO-G474RE which can be found here most likely suffers from the same problems.

MDK-ARM startup assembly files have invalid CMSIS-Pack/Config Wizard Annotations

Please review all MDK-ARM startup_*.s files. Note that these files follow the "CMSIS Config Wizard Annotations" (see: http://arm-software.github.io/CMSIS_5/Pack/html/configWizard.html)

The files contain this code in the header section.

;* <h2><center>&copy; Copyright (c) 2017 STMicroelectronics.
;* All rights reserved.</center></h2>

Which confuses the config annotation parser. Therefore I suggest to move the start tag of the config wizard annotation
;* <<< Use Configuration Wizard in Context Menu >>>
to after the copyright and license (line 27)

;*******************************************************************************
;* <<< Use Configuration Wizard in Context Menu >>>
; Amount of memory (in bytes) allocated for Stack

SPI parameter

Hi,

How to set
hspi1.Init.MasterKeepIOState = SPI_MASTER_KEEP_IO_STATE_ENABLE; parameter in STM32G4 for SPI communication in Poll for conversion method.Its giving me error If I add this in MX_SPI1_Init().

template file system_stm32g4xx.c should support userdefined location of vectortable

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

• The board (either ST RPN reference or your custom board).
• IDE or at least the compiler and its version.

Describe the bug
Same as STMicroelectronics/STM32CubeF4#30
`A clear and concise description of what the bug is.
template file system_stm32g4xx.c should support userdefined location of vectortable
using a custom bootloader requires to move the default location of the vector table.
in the file system_stm32g4xx.c that is copied by the program generator is the needed settings for the move of the vector table.
But the user can not control this behaviour by compiler command arguments
in the defines section at the beginning of the file line 92ff
the lines:
/* #define VECT_TAB_SRAM /
#define VECT_TAB_OFFSET 0x00 /!< Vector Table base offset field.
This value must be a multiple of 0x200. /
/*****************************************************************************/

have to be changed to
/* #define VECT_TAB_SRAM /
#if !defined(VECT_TAB_OFFSET)
#define VECT_TAB_OFFSET 0x00 /!< Vector Table base offset field.
This value must be a multiple of 0x200. /
#endif
/*****************************************************************************/

So the user can control the define from compiler command arguments.
This allows targets for bootloader or plain memory layout.

All the existing code will not break.`

How To Reproduce

1. Indicate the global behavior of your application project.

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).

3. The use case that generates the problem.

4. How we can reproduce the problem.

Additional context
If you have a first analysis or patch correction, thank you to share your proposal.

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

The value passed to LL_RCC_SetAPB2Prescaler is incorrect

Describe the set-up

• Board: NUCLEO-G431RB
• STM32CubeG4: v1.2.0
• Compiler and its version: arm-none-eabi-gcc (xPack GNU Arm Embedded GCC, 32-bit) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

Describe the bug
LL_RCC_SetAPB2Prescaler is called in Projects/NUCLEO-G431RB/Examples_LL/UTILS/UTILS_ConfigureSystemClock/Src/main.c to set the APB2 prescaler on this line:

  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);

The value passed to LL_RCC_SetAPB2Prescaler is LL_RCC_APB1_DIV_1 which is incorrect. The correct value to pass to LL_RCC_SetAPB2Prescaler is LL_RCC_APB2_DIV_1.

At the end of the day this doesn't actually cause any problems because both LL_RCC_APB1_DIV_1 and LL_RCC_APB2_DIV_1 are defined as 0. However, it would still make sense to use LL_RCC_APB2_DIV_1 rather than LL_RCC_APB1_DIV_1 when appropriate.

Additional context
There are several other occurrences of this issue in the code.

$ grep -rn LL_RCC_SetAPB2Prescaler | grep LL_RCC_APB1_DIV_1
NUCLEO-G474RE/Examples_LL/ADC/ADC_SingleConversion_TriggerSW_IT_Init/Src/main.c:260:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/ADC/ADC_AnalogWatchdog_Init/Src/main.c:270:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/ADC/ADC_ContinuousConversion_TriggerSW_Init/Src/main.c:323:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/ADC/ADC_SingleConversion_TriggerSW_Init/Src/main.c:318:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/ADC/ADC_GroupsRegularInjected_Init/Src/main.c:317:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/ADC/ADC_Oversampling_Init/Src/main.c:386:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/DMA/DMA_CopyFromFlashToMemory_Init/Src/main.c:207:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/PWR/PWR_EnterStandbyMode/Src/main.c:183:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/PWR/PWR_EnterStopMode/Src/main.c:182:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/LPTIM/LPTIM_PulseCounter_Init/Src/main.c:170:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/SPI/SPI_TwoBoards_FullDuplex_DMA_Slave_Init/Src/main.c:233:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/SPI/SPI_OneBoard_HalfDuplex_IT_Init/Src/main.c:213:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/SPI/SPI_TwoBoards_FullDuplex_DMA_Master_Init/Src/main.c:239:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/WWDG/WWDG_RefreshUntilUserEvent_Init/Src/main.c:180:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RNG/RNG_GenerateRandomNumbers/Src/main.c:188:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RNG/RNG_GenerateRandomNumbers_IT/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/LPUART/LPUART_WakeUpFromStop_Init/Src/main.c:194:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/LPUART/LPUART_WakeUpFromStop/Src/main.c:204:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/CORDIC/CORDIC_CosSin/Src/main.c:212:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/COMP/COMP_CompareGpioVsVrefInt_OutputGpio_Init/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/COMP/COMP_CompareGpioVsVrefInt_IT_Init/Src/main.c:181:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/GPIO/GPIO_InfiniteLedToggling_Init/Src/main.c:165:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_Communication_Rx_IT_Continuous_Init/Src/main.c:206:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_Communication_Tx_Init/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_WakeUpFromStop_Init/Src/main.c:200:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_Communication_Tx_IT_Init/Src/main.c:182:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_Communication_Rx_IT_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/USART/USART_Communication_TxRx_DMA_Init/Src/main.c:195:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RTC/RTC_ExitStandbyWithWakeUpTimer_Init/Src/main.c:220:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RTC/RTC_TimeStamp_Init/Src/main.c:272:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RTC/RTC_ProgrammingTheWakeUpTimer/Src/main.c:222:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RTC/RTC_Alarm_Init/Src/main.c:275:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RTC/RTC_Tamper_Init/Src/main.c:221:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/CRC/CRC_UserDefinedPolynomial/Src/main.c:199:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/CRC/CRC_CalculateAndCheck/Src/main.c:191:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_OneBoard_Communication_PollingAndIT_Init/Src/main.c:205:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_OneBoard_AdvCommunication_DMAAndIT_Init/Src/main.c:273:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_TwoBoards_MasterTx_SlaveRx_DMA_Init/Src/main.c:235:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_TwoBoards_MasterRx_SlaveTx_IT_Init/Src/main.c:207:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_OneBoard_Communication_IT_Init/Src/main.c:194:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_TwoBoards_MasterTx_SlaveRx_Init/Src/main.c:240:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_TwoBoards_WakeUpFromStop_IT_Init/Src/main.c:203:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/I2C/I2C_OneBoard_Communication_DMAAndIT_Init/Src/main.c:218:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_DMA_Init/Src/main.c:231:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_BreakAndDeadtime_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_OnePulse_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_InputCapture_Init/Src/main.c:229:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_PWMOutput_Init/Src/main.c:216:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/TIM/TIM_OutputCompare_Init/Src/main.c:206:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/EXTI/EXTI_ToggleLedOnIT/Src/main.c:160:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/EXTI/EXTI_ToggleLedOnIT_Init/Src/main.c:160:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RCC/RCC_UseHSI_PLLasSystemClock/Src/main.c:226:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RCC/RCC_OutputSystemClockOnMCO/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/RCC/RCC_UseHSEasSystemClock/Src/main.c:183:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/HRTIM/HRTIM_Basic_PWM_Master/Src/main.c:175:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/HRTIM/HRTIM_Basic_Multiple_PWM/Src/main.c:180:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/HRTIM/HRTIM_Basic_Single_PWM/Src/main.c:181:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/HRTIM/HRTIM_CBC_Deadtime/Src/main.c:174:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/HRTIM/HRTIM_Basic_Arbitrary_Waveform/Src/main.c:173:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/CRS/CRS_Synchronization_IT/Src/main.c:280:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/CRS/CRS_Synchronization_Polling/Src/main.c:240:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/UTILS/UTILS_ReadDeviceInfo/Src/main.c:165:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/UTILS/UTILS_ConfigureSystemClock/Src/main.c:191:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/DAC/DAC_GenerateConstantSignal_TriggerSW_Init/Src/main.c:198:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/DAC/DAC_GenerateConstantSignal_TriggerSW_LP_Init/Src/main.c:227:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G474RE/Examples_LL/DAC/DAC_GenerateWaveform_TriggerHW_Init/Src/main.c:330:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_SingleConversion_TriggerSW_IT_Init/Src/main.c:260:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_AnalogWatchdog_Init/Src/main.c:270:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_ContinuousConversion_TriggerSW_Init/Src/main.c:323:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_SingleConversion_TriggerSW_Init/Src/main.c:318:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_GroupsRegularInjected_Init/Src/main.c:317:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/ADC/ADC_Oversampling_Init/Src/main.c:386:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/DMA/DMA_CopyFromFlashToMemory_Init/Src/main.c:207:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/PWR/PWR_EnterStandbyMode/Src/main.c:183:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/PWR/PWR_EnterStopMode/Src/main.c:182:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/LPTIM/LPTIM_PulseCounter_Init/Src/main.c:170:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/SPI/SPI_TwoBoards_FullDuplex_DMA_Slave_Init/Src/main.c:233:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/SPI/SPI_OneBoard_HalfDuplex_IT_Init/Src/main.c:213:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/SPI/SPI_TwoBoards_FullDuplex_DMA_Master_Init/Src/main.c:239:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/WWDG/WWDG_RefreshUntilUserEvent_Init/Src/main.c:180:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RNG/RNG_GenerateRandomNumbers/Src/main.c:188:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RNG/RNG_GenerateRandomNumbers_IT/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/LPUART/LPUART_WakeUpFromStop_Init/Src/main.c:194:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/LPUART/LPUART_WakeUpFromStop/Src/main.c:204:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/CORDIC/CORDIC_CosSin/Src/main.c:212:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/COMP/COMP_CompareGpioVsVrefInt_OutputGpio_Init/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/COMP/COMP_CompareGpioVsVrefInt_IT_Init/Src/main.c:181:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/GPIO/GPIO_InfiniteLedToggling_Init/Src/main.c:165:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_Communication_Rx_IT_Continuous_Init/Src/main.c:206:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_Communication_Tx_Init/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_WakeUpFromStop_Init/Src/main.c:200:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_Communication_Tx_IT_Init/Src/main.c:182:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_Communication_Rx_IT_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/USART/USART_Communication_TxRx_DMA_Init/Src/main.c:195:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RTC/RTC_ExitStandbyWithWakeUpTimer_Init/Src/main.c:220:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RTC/RTC_TimeStamp_Init/Src/main.c:272:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RTC/RTC_ProgrammingTheWakeUpTimer/Src/main.c:222:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RTC/RTC_Alarm_Init/Src/main.c:275:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RTC/RTC_Tamper_Init/Src/main.c:215:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/CRC/CRC_UserDefinedPolynomial/Src/main.c:199:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/CRC/CRC_CalculateAndCheck/Src/main.c:191:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_OneBoard_Communication_PollingAndIT_Init/Src/main.c:205:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_OneBoard_AdvCommunication_DMAAndIT_Init/Src/main.c:273:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_TwoBoards_MasterTx_SlaveRx_DMA_Init/Src/main.c:235:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_TwoBoards_MasterRx_SlaveTx_IT_Init/Src/main.c:207:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_OneBoard_Communication_IT_Init/Src/main.c:194:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_TwoBoards_MasterTx_SlaveRx_Init/Src/main.c:240:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_TwoBoards_WakeUpFromStop_IT_Init/Src/main.c:203:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/I2C/I2C_OneBoard_Communication_DMAAndIT_Init/Src/main.c:218:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_DMA_Init/Src/main.c:231:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_BreakAndDeadtime_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_OnePulse_Init/Src/main.c:177:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_InputCapture_Init/Src/main.c:229:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_PWMOutput_Init/Src/main.c:216:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/TIM/TIM_OutputCompare_Init/Src/main.c:206:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/EXTI/EXTI_ToggleLedOnIT/Src/main.c:160:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/EXTI/EXTI_ToggleLedOnIT_Init/Src/main.c:160:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RCC/RCC_UseHSI_PLLasSystemClock/Src/main.c:226:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RCC/RCC_OutputSystemClockOnMCO/Src/main.c:193:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/RCC/RCC_UseHSEasSystemClock/Src/main.c:183:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/CRS/CRS_Synchronization_IT/Src/main.c:280:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/CRS/CRS_Synchronization_Polling/Src/main.c:240:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/UTILS/UTILS_ReadDeviceInfo/Src/main.c:165:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/UTILS/UTILS_ConfigureSystemClock/Src/main.c:191:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/DAC/DAC_GenerateConstantSignal_TriggerSW_Init/Src/main.c:198:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
NUCLEO-G431RB/Examples_LL/DAC/DAC_GenerateConstantSignal_TriggerSW_LP_Init/Src/main.c:227:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
B-G474E-DPOW1/Applications/USB-PD/USB-PD_Consumer_1port/Src/main.c:199:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
STM32G474E-EVAL/Applications/USB-PD/USB-PD_Provider_1port/Src/main.c:199:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);
STM32G474E-EVAL/Applications/USB-PD/USB-PD_Consumer_1port/Src/main.c:199:  LL_RCC_SetAPB2Prescaler(LL_RCC_APB1_DIV_1);

HAL_GPIO doesn't have EXTI enable / disable API.

The EXTI interrupt is caught by the HAL_GPIO_EXTI_Callback(). But there is not HAL_GPIO API to enable / disable EXTI.

This is not appropriate design. Some API to enable / disable EXTI for each line should be provided.

HAL_RTC_Init() loses time

Same issue as STMicroelectronics/STM32CubeH7#24 and STMicroelectronics/STM32CubeF1#58. HAL_RTC_Init() is called on each reset which loses up to a second of time.

Readme on NUCLEO-G474RE/Examples/OPAMP/OPAMP_PGA/readme.txt

in

STM32CubeG4/Projects/NUCLEO-G474RE/Examples/OPAMP/OPAMP_PGA/readme.txt

Line 51 in 3e5243a

- Connect a wire between DAC output (PA4 - pin 32 on connector CN7) to OPAMP non inverting input (PB0 - pin 34 on connector CN7)

non inverting input (PB0 - pin 34 on connector CN7) >> should be >> non inverting input (PA1 - pin 30 on connector CN7)

OPAMP

ENV

• arm-none-eabi-gcc 9.2.1 20191025 (release)

Describe the bug
When I use OPAMP3->ADC3 with PGA connect(OPAMP_PGA_GAIN_xOR_MINUSx-1), the output rate is 2*x-1 instead x

The reference input is from ADC1

The GNU Link Script in STM32CubeG4/Projects/NUCLEO-G491RE/Templates/STM32CubeIDE/STM32G491RETX_FLASH.ld defines wrong RAM size

The RAM size(128KB) defined in template gnu link script exceed the real value, which should be 112 KB according to the g491 datasheet. This wrong parameter might cause hard fault during function call, since the sp register point to an illegal address.

/* Memories definition */ MEMORY { CCMSRAM (xrw) : ORIGIN = 0x10000000, LENGTH = 16K RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K ROM (rx) : ORIGIN = 0x08000000, LENGTH = 512K }

Timer Prescaler Setting Math operation will produce wrong code

Describe the set-up

• The board : NUCLEO-G474RE
• IDE or at least the compiler and its version : CubeIDe 1.5.1 and CubeMX 6.1.1-RC2, F1.3.0
• Win10

Describe the bug
TIM6 LL in CubeIDE/MX prescaler cannot use math operation like 170 - 1, (170-1), 170-2, etc.
This is not a problem with ARR.

Screenshots

module DAC does not work on STMG473

I use MX cube to generate code with STM32Cube_FW_G4_V1.3.0 package but after this
/* USER CODE BEGIN 2 /
HAL_DAC_Start(&hdac1,DAC1_CHANNEL_1);
HAL_DAC_SetValue(&hdac1,DAC1_CHANNEL_1,DAC_ALIGN_12B_R,2000);
/ USER CODE END 2 */
I measured on PA4 is 0V. This code work normally with other STM32 which I tested ( STM32F4, STM32F1)
I do not know how to fix this. Help me out. Thanks.