Currently, the stm32f4xx_hal_i2c.h has the following definition of I2C_Memory_Address_Size:

/** @defgroup I2C_Memory_Address_Size I2C Memory Address Size
  * @{
  */
#define I2C_MEMADD_SIZE_8BIT            0x00000001U
#define I2C_MEMADD_SIZE_16BIT           0x00000010U
/**
  * @}
  */

The value for 8-bit memory address is 1 (byte) as expected, but the value for 16-bit address is 16. In other repositories this definition has a value of 2.

I'm working with stm32f411re uC and a TI audiocodec through I2S2 interface in full duplex master.
I generate the project using CubeMx 5.5 and HAL driver 1.24.2.
I configure the I2S module to use DMA on both, tx and rx in circular mode. I need to check HalfComplete and Complete transfer in order to prepare/process received data.

But HAL driver prevents Complete callback to be called in circular mode, which is a hug bug. This bug is not present on older versions of the library.
I've reported this one year ago:
https://community.st.com/s/question/0D50X0000AAIIetSQH/i2s-dma-complete-transfer-irq-on-circular-mode

The problem is here
https://github.com/STMicroelectronics/stm32f4xx_hal_driver/blob/7fabee45fb2cbe2189dd40cbe677917448510258/Src/stm32f4xx_hal_i2s_ex.c#L872 :

/**
  * @brief  DMA I2S transmit receive process complete callback
  * @param  hdma pointer to a DMA_HandleTypeDef structure that contains
  *               the configuration information for the specified DMA module.
  * @retval None
  */
static void I2SEx_TxRxDMACplt(DMA_HandleTypeDef *hdma)
{
  I2S_HandleTypeDef *hi2s = (I2S_HandleTypeDef *)((DMA_HandleTypeDef *)hdma)->Parent;

  /* if DMA is configured in DMA_NORMAL mode */
  if (hdma->Init.Mode == DMA_NORMAL)
  {
    if (hi2s->hdmarx == hdma)
    {
      /* Disable Rx DMA Request */
      if (((hi2s->Instance->I2SCFGR & SPI_I2SCFGR_I2SCFG) == I2S_MODE_MASTER_TX) || \
          ((hi2s->Instance->I2SCFGR & SPI_I2SCFGR_I2SCFG) == I2S_MODE_SLAVE_TX))
      {
        CLEAR_BIT(I2SxEXT(hi2s->Instance)->CR2, SPI_CR2_RXDMAEN);
      }
      else
      {
        CLEAR_BIT(hi2s->Instance->CR2, SPI_CR2_RXDMAEN);
      }

      hi2s->RxXferCount = 0U;

      if (hi2s->TxXferCount == 0U)
      {
        hi2s->State = HAL_I2S_STATE_READY;

        /* Call user TxRx complete callback */
#if (USE_HAL_I2S_REGISTER_CALLBACKS == 1U)
        hi2s->TxRxCpltCallback(hi2s);
#else
        HAL_I2SEx_TxRxCpltCallback(hi2s);
#endif /* USE_HAL_I2S_REGISTER_CALLBACKS */
      }
    }

    if (hi2s->hdmatx == hdma)
    {
      /* Disable Tx DMA Request */
      if (((hi2s->Instance->I2SCFGR & SPI_I2SCFGR_I2SCFG) == I2S_MODE_MASTER_TX) || \
          ((hi2s->Instance->I2SCFGR & SPI_I2SCFGR_I2SCFG) == I2S_MODE_SLAVE_TX))
      {
        CLEAR_BIT(hi2s->Instance->CR2, SPI_CR2_TXDMAEN);
      }
      else
      {
        CLEAR_BIT(I2SxEXT(hi2s->Instance)->CR2, SPI_CR2_TXDMAEN);
      }

      hi2s->TxXferCount = 0U;

      if (hi2s->RxXferCount == 0U)
      {
        hi2s->State = HAL_I2S_STATE_READY;

        /* Call user TxRx complete callback */
#if (USE_HAL_I2S_REGISTER_CALLBACKS == 1U)
        hi2s->TxRxCpltCallback(hi2s);
#else
        HAL_I2SEx_TxRxCpltCallback(hi2s);
#endif /* USE_HAL_I2S_REGISTER_CALLBACKS */
      }
    }
  }
}

The first check is DMA is configured in NORMAL mode. But that prevents the DMA complete callback to fire an IRQ in CIRCULAR mode, which I can't explain why is that!!!!

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
I am using STM32 on win32 and Keil-MDK and auto generated project using CubeMX 5.6.1. and STM32F4-1.25.
This comes with lwip 2.1.2

Using the ARM Keil compiler version 6 ARM-CC 6.14 clang based compiler, I run into compiler problem.

Describe the bug

../Middlewares/Third_Party/LwIP/system\arch/cc.h(46): error: 'sys/time.h' file not found
#include <sys/time.h>
^~~~~~~~~~~~

in file cc.h line 44ff
...
>#if defined (GNUC) & !defined (__CC_ARM)
>
>#define LWIP_TIMEVAL_PRIVATE 0
>#include <sys/time.h>
>
>#endif

...

How To Reproduce

1. Indicate the global behavior of your application project.
   switch in the Keil uVision IDE compiler generation 5 to compiler generation 6 (this is clang based)
   compile using Keil uvision IDE

2. The modules that you suspect to be the cause of the problem (Driver, BSP, MW ...).
   LWIP module does not compile

3. The use case that generates the problem.
   using the default compiler with current ARM development set

4. How we can reproduce the problem.
   follow 1)

Additional context

The test for compiler is not correct (i assume).
There are other tests in cmsis_compiler.h 33ff
...

>/*
> * Arm Compiler 4/5
> */
>#if   defined ( __CC_ARM )
>  #include "cmsis_armcc.h"
>
>
>/*
> * Arm Compiler 6 (armclang)
> */
>#elif defined (__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050)
>  #include "cmsis_armclang.h"
>
>
>/*
> * GNU Compiler
> */
>#elif defined ( _GNUC_ )
>  #include "cmsis_gcc.h"

..

I can resolve this error using following patch which applies the test logic of cmsis_compiler.h on that in cc.h

Index: cc.h

--- cc.h (revision 18447)
+++ cc.h (working copy)
@@ -40,7 +40,7 @@

#define LWIP_PROVIDE_ERRNO

-#if defined (GNUC) & !defined (__CC_ARM)
+#if defined (GNUC) && !defined (__CC_ARM) && !(defined(__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050))

#define LWIP_TIMEVAL_PRIVATE 0
#include <sys/time.h>

I checked the lwip git repository.
There is no such file for STM32 or cortexM controller.
So I think this is not up to lwip to fix but rather STM must fix this bug.

Hoever there is no clear ownership of this file .

regards, Adib.

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

I am developing the RTC function with HAL library on STM32F4. There is a confuss on the bit position of timeformat for RTC register operation.

In the source code, the TimeFormat position of HAL_RTC_SetTime is 16:

Yet in the Reference manual (RM0430, page 760), it says:

It happens on other functions, such as HAL_RTC_GetTime, HAL_RTC_GetAlarm, HAL_RTC_SetAlarm.
Could you share why the bit position of TimeFormat is 16?

Setup

• Latest version of git
• Any compiler

Describe the bug
Unable to compile code

How To Reproduce

1. Clone the repository: git clone https://github.com/STMicroelectronics/STM32CubeF4.git
2. Locate any .c file

Unexpected Behavior
Unable to find any source code containing the STM32CubeF4 package.

Expected Behavior
Repository should contain latest version of code from STM32CubeF4. The source code should match download from STMicroelectronics website tools and software part number STM32CubeF4

Screenshots

Possible bug in HAL_I2C_Mem_Read_IT, reported in the forum.

In stm32f4xx_hal_i2c.c near line 4597

Hi Community,

I find a bug in STM32CubeF4 Ver 1.25.0 stm32f4xx_hal_rcc.c line 546.

This wil return HAL_ERROR when the register is correct.

​ /* Do not return HAL_ERROR if request repeats the current configuration */
pll_config = RCC->PLLCFGR;
if((READ_BIT(pll_config, RCC_PLLCFGR_PLLSRC) != RCC_OscInitStruct->PLL.PLLSource) ||
(READ_BIT(pll_config, RCC_PLLCFGR_PLLM) != RCC_OscInitStruct->PLL.PLLM) ||
(READ_BIT(pll_config, RCC_PLLCFGR_PLLN) != RCC_OscInitStruct->PLL.PLLN) ||
(READ_BIT(pll_config, RCC_PLLCFGR_PLLP) != RCC_OscInitStruct->PLL.PLLP) ||
(READ_BIT(pll_config, RCC_PLLCFGR_PLLQ) != RCC_OscInitStruct->PLL.PLLQ))
{
return HAL_ERROR;
}

​base on stm32f4xx_hal_rcc.c line 497:

​ /* Configure the main PLL clock source, multiplication and division factors. */
WRITE_REG(RCC->PLLCFGR, (RCC_OscInitStruct->PLL.PLLSource |
RCC_OscInitStruct->PLL.PLLM |
(RCC_OscInitStruct->PLL.PLLN << RCC_PLLCFGR_PLLN_Pos) |
(((RCC_OscInitStruct->PLL.PLLP >> 1U) - 1U) << RCC_PLLCFGR_PLLP_Pos) |
(RCC_OscInitStruct->PLL.PLLQ << RCC_PLLCFGR_PLLQ_Pos)));

and stm32f4xx_hal_rcc.h line 497:

/** @defgroup RCC_PLLP_Clock_Divider PLLP Clock Divider

• @{
  */
  #define RCC_PLLP_DIV2 0x00000002U
  #define RCC_PLLP_DIV4 0x00000004U
  #define RCC_PLLP_DIV6 0x00000006U
  #define RCC_PLLP_DIV8 0x00000008U

and RM009 page 164:
​

Bits 17:16 PLLP: Main PLL (PLL) division factor for main system clock
Set and cleared by software to control the frequency of the general PLL output clock. These
bits can be written only if PLL is disabled.
Caution: The software has to set these bits correctly not to exceed 180 MHz on this domain.
PLL output clock frequency = VCO frequency / PLLP with PLLP = 2, 4, 6, or 8

00: PLLP = 2
01: PLLP = 4
10: PLLP = 6
11: PLLP = 8

stm32f4xx_hal_rcc.c line 546:

(READ_BIT(pll_config, RCC_PLLCFGR_PLLP) != RCC_OscInitStruct->PLL.PLLP) ||

should be replace by :

(READ_BIT(pll_config, RCC_PLLCFGR_PLLP) != ((RCC_OscInitStruct->PLL.PLLP >> 1U) - 1U)) ||

Describe the set-up
Board:
STM32F413 Nucleo-144
Software:
STM32Cube_FW_F4_V1.24.1
STMCubeMX version 5.4.0
Atollic TrueSTUDIO® Version: 9.3.0 Build id: 20190212-0734

Describe the bug
In the if statement which sets configures the BRR (in stm32f4xx_hal_uart.c starting at line 3071) there are special cases for USART1 and USART 6 (because they're clocked from Peripheral Bus 2 (PB2)) but UART9 and UART10 (which are also clocked from PB2) are not included in this special case. This results in the baud rate of these UARTs being calculated from the clock rate of PB1 and so the baud rate of these 2 UARTS comes out as (desired baud rate)*(PB1 clock frequency)/(PB2 clock frequency)

How To Reproduce
Start a new project in STM32CubeMX loaded with STM32Cube_FW_F4_V1.24.1.
Initialise UART9 or UART10 in Asynchronous Mode.
Generate project.
Add "HAL_UART_Transmit(&huart9, (uint8_t*)"Hello\r\n", 7, HAL_MAX_DELAY);" or "HAL_UART_Transmit(&huart10, (uint8_t*)"Hello\r\n", 7, HAL_MAX_DELAY);" into the superloop in main(). Depending on which UART you have initialised.
Connect an STM32F413 Nucleo-144 and make a serial connection with pin PG1/ Nucleo header D64 (UART 9) or pin PE3/ Nucleo header PE3 (UART 10).
Open up a terminal at 115200 baud and connect to the board.
Debug the project.
This should print out gibberish.
If the baud is set to 230400 or the clock frequency of PB2 is set to 48MHz then it will repeatedly print out Hello as it should.

Additional context
I suggest that the instances of UART 9 and UART10 are added to the conditions of these 4 if statements.
Proposed new code (stm32f4xx_hal_uart.c starting at line 3071):

  /* Check the Over Sampling */
  if (huart->Init.OverSampling == UART_OVERSAMPLING_8)
  {
    /*-------------------------- USART BRR Configuration ---------------------*/
#if defined(USART6)
    if ((huart->Instance == USART1) || (huart->Instance == USART6) || (huart->Instance == UART9) || (huart->Instance == UART10))
    {
      huart->Instance->BRR = UART_BRR_SAMPLING8(HAL_RCC_GetPCLK2Freq(), huart->Init.BaudRate);
    }
#else
    if ((huart->Instance == USART1) || (huart->Instance == UART9) || (huart->Instance == UART10))
    {
      huart->Instance->BRR = UART_BRR_SAMPLING8(HAL_RCC_GetPCLK2Freq(), huart->Init.BaudRate);
    }
#endif /* USART6 */
    else
    {
      huart->Instance->BRR = UART_BRR_SAMPLING8(HAL_RCC_GetPCLK1Freq(), huart->Init.BaudRate);
    }
  }
  else
  {
    /*-------------------------- USART BRR Configuration ---------------------*/
#if defined(USART6)
    if ((huart->Instance == USART1) || (huart->Instance == USART6) || (huart->Instance == UART9) || (huart->Instance == UART10))
    {
      huart->Instance->BRR = UART_BRR_SAMPLING16(HAL_RCC_GetPCLK2Freq(), huart->Init.BaudRate);
    }
#else
    if ((huart->Instance == USART1) || (huart->Instance == UART9) || (huart->Instance == UART10))
    {
      huart->Instance->BRR = UART_BRR_SAMPLING16(HAL_RCC_GetPCLK2Freq(), huart->Init.BaudRate);
    }
#endif /* USART6 */
    else
    {
      huart->Instance->BRR = UART_BRR_SAMPLING16(HAL_RCC_GetPCLK1Freq(), huart->Init.BaudRate);
    }
  }

Screenshots
Current state of the if statement:

Suggested change:

1. Why are these not marked as const:
   

   STM32CubeF4/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Src/usbd_cdc.c

   Line 255 in 2d5b78e

   __ALIGN_BEGIN static uint8_t USBD_CDC_CfgFSDesc[USB_CDC_CONFIG_DESC_SIZ] __ALIGN_END =

   
   Because of non-constness, they are placed in RAM. However, they are not modified at runtime so making them const would save 3*67Bytes in RAM.

And while we are looking at this file:

2. Why is there even a descriptor for "other speed" ? It sets the bDescriptorType field to 7, I cannot find any documentation for this value on the internet. Why is it not 0x2?

3. The documentation for the different fields in the descriptors is different for "high speed" / "full speed" / "other speed". Please consolidate that.

We have been facing some trouble using the SD card library to read and write data to and from an SD card with an STM32F429ZI. We are using the ff.h FatFs - Generic FAT file system module R0.12c library. What we have observed is that after a few reads and writes, the STM goes into a hard fault crash or a FR_DISK_ERR is returned. This was observed while running the debugger. We have tried multiple ways, even mounting the SD card and unmounting it before and after every read/write attempt. We have tried with 2gb and 4gb sd cards. The SD card used was formatted using both FAT default and FAT32.

I ran into the following issues when trying to send a transaction that is split into multiple transfers.

1. The code here does not take into account the FIFO size.

2. For large transfers, the code here enables the ptxfempty interrupt, but the interrupt handles ignores it as seen in

   STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_hcd.c

   Lines 521 to 524 in 9f5ea74

   	if (__HAL_HCD_GET_FLAG(hhcd, USB_OTG_GINTSTS_PTXFE))
   	{
   	/* Incorrect mode, acknowledge the interrupt */
   	__HAL_HCD_CLEAR_FLAG(hhcd, USB_OTG_GINTSTS_PTXFE);

Am I missing something or this functionality just super broken?

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.
  Project generated by CubeMX

Describe the bug
A clear and concise description of what the bug is.
template file system_stm32f4xx.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_stm32f4xx.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.

Hi,

I have some issues using SMBus. The source file which I suspect to be the cause of problems is stm32f4xx_hal_smbus.c. Use cases which I found the issues are described below.

1. If I use HAL_SMBUS_Master_Transmit_IT with SMBUS_FIRST_AND_LAST_FRAME_NO_PEC XferOptions, STOP is not generated. I suspect the condition in line 1934 and 2020. Shouldn't all conditions be ANDed together?
   

   STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smbus.c

   Lines 1933 to 1936 in 2d5b78e

   	/* Call TxCpltCallback() directly if no stop mode is set */
   	if (((CurrentXferOptions != SMBUS_FIRST_AND_LAST_FRAME_NO_PEC) || (CurrentXferOptions != SMBUS_FIRST_AND_LAST_FRAME_WITH_PEC)) && \
   	((CurrentXferOptions != SMBUS_LAST_FRAME_NO_PEC) || (CurrentXferOptions != SMBUS_LAST_FRAME_WITH_PEC)) && (CurrentXferOptions != SMBUS_NO_OPTION_FRAME))
   	{

   
   

   STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smbus.c

   Lines 2019 to 2021 in 2d5b78e

   	/* Call TxCpltCallback() directly if no stop mode is set */
   	if (((CurrentXferOptions != SMBUS_FIRST_AND_LAST_FRAME_NO_PEC) || (CurrentXferOptions != SMBUS_FIRST_AND_LAST_FRAME_WITH_PEC)) && ((CurrentXferOptions != SMBUS_LAST_FRAME_NO_PEC) || (CurrentXferOptions != SMBUS_LAST_FRAME_WITH_PEC)) && (CurrentXferOptions != SMBUS_NO_OPTION_FRAME))
   	{

2. If I use HAL_SMBUS_Master_Receive_IT with SMBUS_LAST_FRAME_NO_PEC XferOptions, STOP is also not generated. I suspect the condition in line 2169. Shouldn't SMBUS_LAST_FRAME_NO_PEC be deleted from the condition?
   

   STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smbus.c

   Lines 2168 to 2170 in 2d5b78e

   	/* Prepare next transfer or stop current transfer */
   	if ((CurrentXferOptions == SMBUS_NEXT_FRAME) || (CurrentXferOptions == SMBUS_FIRST_FRAME) || (CurrentXferOptions == SMBUS_LAST_FRAME_NO_PEC))
   	{

3. Not a bug, but I found that HAL_SMBUS_ErrorCallback is called twice in line 2714.
   

   STM32CubeF4/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_smbus.c

   Lines 2713 to 2719 in 2d5b78e

   	/* Call user error callback */
   	HAL_SMBUS_ErrorCallback(hsmbus);
   	#if (USE_HAL_SMBUS_REGISTER_CALLBACKS == 1)
   	hsmbus->ErrorCallback(hsmbus);
   	#else
   	HAL_SMBUS_ErrorCallback(hsmbus);
   	#endif /* USE_HAL_SMBUS_REGISTER_CALLBACKS */

Regards

The error code should be HAL_SMBUS_ERROR_PECERR instead.

Hello, reading the documentation above to initialize the CAN1 interface on my STM32F4, I cannot find the __HAL_RCC_CAN1_CLK_ENABLE() function anywhere in the code. Should this documentation be updated? Additionally, how do we initialize the RCC_CAN1_CLK now?

I don't have a full setup or reproduction of the issue, because I found it on a code review on a different project. It is in regards to the code linked below:

From what I understand in the above linked code, the buffer is being "freed" back to the DMA on line 429 and then being accessed again on line 430. What would happen if a DMA interrupt were to occur between these two lines of code? It appears to me that this has the potential to point to the wrong buffer causing memory leaks or other issues. A safe version of lines 429-430 would be as follows:

    __IO ETH_DMADescTypeDef *next = (ETH_DMADescTypeDef *)(dmarxdesc->Buffer2NextDescAddr);
    dmarxdesc->Status |= ETH_DMARXDESC_OWN;
    dmarxdesc = next;

This code appares to be implemented in many other cube libraries as well.

Describe the set-up

• stm32f446re
• arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

Describe the bug
warning: ISO C++17 does not allow 'register' storage class specifier [-Wregister]

How To Reproduce

1. Compile with -std=gnu++2a or -std=gnu++17

Additional context
Ther warnings show in several different files including stm32f4xx_ll_usart.h, stm32f4xx_ll_tim.h, stm32f4xx_ll_adc.h, stm32f4xx_ll_rtc.h, etc. I believe the register keyword should just be removed as its been deprecated since C++11, removed since C++17 and compilers havent used it for a long long time. Would u accept a pr removing use of this keyword?

ARM also removed the use of the "register" keyword in cmsis:
ARM-software/CMSIS_5@f46ec37
ARM-software/CMSIS_5#345

Relevant issue:
ARMmbed/mbed-os#12232

Hi,

can you add composite USB (for example USB MSC + USB CDC) driver to the Middlewares?

I am sure many users will appreciate this. There are only few and mostly outdated/incomplete examples how to get USB MSC + USB CDC working as a composite device.

Regards

Hello,

I was digging through old releases of the CubeF4, it seems that the original example in:

Projects\STM32469I-Discovery\Applications\STemWin\STemWin_HelloWorld

was using the LCD in video mode (1.9.0 release), then at some point this was abandoned in
the favor of AdaptedCommandMode, which is the current example in 1.25.0.

Off course this is not visible in the History of the LCDConf_stm32469i_discovery.c as the initial
upload of this repo was based on much later release. There are lots of examples that use Video
mode, but those use basic (bare metal) gui libs, not anything more advanced like STemWin.

Do you guys have another more recent and working example of this driver somewhere please ?
As MIPI DSI LCDs with internal GRAM are rare as unicorns, every one that could be bought and
used on a project needs video mode and has no internal RAM. Thank you!

Regards, Krassi

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.
  I use STM32F437VGT powered by battery (not USB).
  I use CubeMX for setup and Initialisation
  USB_FS is is configured as CDC device.
  MX_USB_DEVICE_Init is called by application not by main().

Describe the bug
A clear and concise description of what the bug is.
After detecting the USB cable is detached the application calls usbd_core.c:USBD_DeInit() function.
The goal is to detach USB from the USB pins to avoid unneeded PULL UP voltage on that pins.

The Problem is that the function USBD_DeInit() aborts with errorr code halfway and does not release USB from USB Pins.

1. USBD_LL_Stop does report USBD_TIMEOUT instead USBD_OK
2. function return
3. USBD_LL_DeInit is not called
   that would lead to USB detach USB pins

How To Reproduce

1. Indicate the global behavior of your application project.

1. start main
2. attach USB cable
3. call MX_USB_DEVICE_Init() -> PC does enumeration
4. detach USB cable
5. call USBD_DeInit -> function returns halfway and does not call USBD_LL_DeInit

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

1. in file stm32f4xx_ll_usb.c line:1070 function USB_StopDevice is wrongly implemented.

2. in file stm32f4xx_ll_usb.c line:477 function USB_FlushRxFifo is wrongly implemented.

3. in file stm32f4xx_ll_usb.c line:454 function USB_FlushTxFifo is wrongly implemented.

4. the silicon has defects
   **

5. does not respect the real number of endpoints in the specific device

HAL_StatusTypeDef USB_StopDevice(USB_OTG_GlobalTypeDef *USBx)
...
  /* Clear Pending interrupt */
  for (i = 0U; i < 15U; i++)
  {
    USBx_INEP(i)->DIEPINT = 0xFB7FU;
    USBx_OUTEP(i)->DOEPINT = 0xFB7FU;
  }
...

according to datasheet for STM32F437 on the FS device i is in range 0..3 and for HS device i in range 0..7
So there must be differentiation of FS and HS device and respect the range.

1. should ignore errors on stopping

HAL_StatusTypeDef USB_StopDevice(USB_OTG_GlobalTypeDef *USBx)
...
  /* Flush the FIFO */
  ret = USB_FlushRxFifo(USBx);
  if (ret != HAL_OK)
  {
    return ret;
  }

  ret = USB_FlushTxFifo(USBx,  0x10U);
  if (ret != HAL_OK)
  {
    return ret;
  }

The initial problem could be avoided if there is no test of return value on USB_FlushRxFifo(USBx) and USB_FlushTxFifo(USBx, 0x10U).
So please do not test the return in the StopDevice() function.

2. the function deserves a synchronisation barrier and more testing

HAL_StatusTypeDef USB_FlushRxFifo(USB_OTG_GlobalTypeDef *USBx)
{
...
    }
    __DSB();
  }
  while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_RXFFLSH) == USB_OTG_GRSTCTL_RXFFLSH);

  return HAL_OK;
}

also in the registerdescription is is pointed out that care must be taken when accessing the flush function is the fifo is still in use.
I do not see such test.

3. the function deserves a synchronisation barrier and more testing

HAL_StatusTypeDef USB_FlushTxFifo(USB_OTG_GlobalTypeDef *USBx, uint32_t num)
...
    }
    __DSB();
  }
  while ((USBx->GRSTCTL & USB_OTG_GRSTCTL_TXFFLSH) == USB_OTG_GRSTCTL_TXFFLSH);

also in the registerdescription is is pointed out that care must be taken when accessing the flush function is the fifo is still in use.
I do not see such test.

4. silicon defect
   the problem arises when flushing the RXFIFO.
   The function times-out and return error.
   USBx->GRSTCTL = USB_OTG_GRSTCTL_RXFFLSH;
   after setting the bit, the hardware does not return the register bit.

According to datasheet after setting the RXFIFO flush bit.
"""
The application must wait until the bit is cleared before performing any other operations. This
bit requires 8 clocks (slowest of PHY or AHB clock) to clear.
"""
The bit should be safely cleared within 20000 queries that is implemented.

Hope this helps to improve the driver, regards Adib.

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.

Beginning with Release v1.24.2 of STM32CubeF4 the initialization of MMC in function HAL_MMC_InitCard() fails.

The reason for the failure is, that the required power up waiting time is moved from HAL_MMC_InitCard() into SDIO_PowerState_ON() but the MMC clock enable is still after SDIO_PowerState_ON() resulting in no MMC clock during the waiting time!

The disable/enable of the MMC clock should be reworked.

Problem: STM32F407 can not calculate correct baud rate if MCU is overclocked over 171MHz.

UART Baudrate calculation happens in (i.e.) stm32f4xx_hal_uart.c in function UART_SetConfig(UART_HandleTypeDef *huart).

Inside this function the following line calculates the DIV_Mantissa and DIV_Fraction values for the UART BRR register, which sets up a clock divider for the serial port to be as close as possible to the desired baud rate clock:

huart->Instance->BRR = UART_BRR_SAMPLING8(HAL_RCC_GetPCLK2Freq(), huart->Init.BaudRate);

(There is 16 bit caltulation also, but it is irrelevant for now.)

The function that returns the register value as result is a macro (in stm32f4xx_hal_uart.h).
Inside this macro the return value of HAL_RCC_GetPCLK2Freq() is multiplied by (uint)25, (uint)100, divided by (uint)100, etc.

The return value of HAL_RCC_GetPCLK2Freq() is the system clock frequency in Hz. In a 168MHz environment this is a relatively huge number for the (uint32_t) return type, because this number is later multiplied, divided by the (uint) numbers inside the macro.

My observation is if the system clock frequency is the following:

UART_BRR_SAMPLING8((uint32_t)171798691, (uint32_t)115200) returns 2979,
UART_BRR_SAMPLING8((uint32_t)171798692, (uint32_t)115200) returns 0

This is clearly an overflow, and system clock above 171.8MHz can not calculate the uart baudrate divider.

UART_BRR_SAMPLING8((uint64_t)171798692, (uint32_t)115200) returns 2979 again.

Changing the type from 32 bit uint to 64 bit uint of the first parameter fixes this issue, but getting the clock is coded inside the library and HAL_RCC_GetPCLK2Freq() return uint32_t.

This might be fixed systemwide by changing the return type of HAL_RCC_GetPCLK2Freq() to uint64_t or by changing the macro to force type casting for the first input parameter to 64 bit uint (but then this will fix only the uart related problems).

For now I fix this issue by changing the return type of HAL_RCC_GetPCLK2Freq() to 64 bit, but later I'd like to use the library updates, so please fix this issue if possible or tell me the reason why this function returns such type that may overflow, and what other method should I use then.

Thank You!

When macro is used within an if-else statement, it can lead to ambiguities, when not sourrounded by curly braces.

A better style would be to write:

#define portEND_SWITCHING_ISR( xSwitchRequired ) \
    do \
        { if( xSwitchRequired != pdFALSE ) portYIELD(); \
    } while(0)

Please check this in the file stm32f4xx_hal_i2c.c

//============================================================
if ((hi2c->XferCount == 0U) && (CurrentState == HAL_I2C_STATE_BUSY_TX_LISTEN))
{
/* Last Byte is received, disable Interrupt */
__HAL_I2C_DISABLE_IT(hi2c, I2C_IT_BUF);

/* Set state at HAL_I2C_STATE_LISTEN */
hi2c->PreviousState = I2C_STATE_SLAVE_BUSY_TX;
hi2c->State = HAL_I2C_STATE_LISTEN;

/* Call the corresponding callback to inform upper layer of End of Transfer /
#if (USE_HAL_I2C_REGISTER_CALLBACKS == 1)
hi2c->SlaveTxCpltCallback(hi2c);
#else
HAL_I2C_SlaveTxCpltCallback(hi2c);
#endif / USE_HAL_I2C_REGISTER_CALLBACKS */
}
//============================================================

if ((hi2c->XferCount == 0U) && (CurrentState == HAL_I2C_STATE_BUSY_TX_LISTEN))
must become
if ((hi2c->XferCount == 0U) && (CurrentState == HAL_I2C_STATE_BUSY_TX))

And

hi2c->State = HAL_I2C_STATE_LISTEN;
must become
hi2c->State = HAL_I2C_STATE_READY;

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
USB_CDC receive buffers are declared in the STM_CubeMX.
Those Buffers are not really used in User application.

Describe the bug
A clear and concise description of what the bug is.
STM_CubeMX generates usbd_cdc_if.c
There the buffers

/* USER CODE BEGIN PRIVATE_DEFINES */
/* Define size for the receive and transmit buffer over CDC */
/* It's up to user to redefine and/or remove those define */
#define APP_RX_DATA_SIZE  1024
#define APP_TX_DATA_SIZE  1024
/* USER CODE END PRIVATE_DEFINES */

...

/* Create buffer for reception and transmission           */
/* It's up to user to redefine and/or remove those define */
/** Received data over USB are stored in this buffer      */
uint8_t UserRxBufferFS[APP_RX_DATA_SIZE];

/** Data to send over USB CDC are stored in this buffer   */
uint8_t UserTxBufferFS[APP_TX_DATA_SIZE];

first and only use in the Init Function

/**
  * @brief  Initializes the CDC media low layer over the FS USB IP
  * @retval USBD_OK if all operations are OK else USBD_FAIL
  */
static int8_t CDC_Init_FS(void)
{
  /* USER CODE BEGIN 3 */
  /* Set Application Buffers */
  USBD_CDC_SetTxBuffer(&hUsbDeviceFS, UserTxBufferFS, 0);
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, UserRxBufferFS);
  return (USBD_OK);
  /* USER CODE END 3 */
}

TxBuffer: To give BufferAddress when size is Zero is useless.
RxBuffer: the buffer is only handled when following the call to USBD_CDC_ReceivePacket()
so this call to SetRxBuffer is completely useless.

further calls to Transmit use the user buffer not the buffer from the CDC Interface file

no further use of TX_Buffer on sending
uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
{
  uint8_t result = USBD_OK;
  /* USER CODE BEGIN 7 */
  USBD_CDC_HandleTypeDef *hcdc = (USBD_CDC_HandleTypeDef*)hUsbDeviceFS.pClassData;
  if (hcdc->TxState != 0){
    return USBD_BUSY;
  }
  USBD_CDC_SetTxBuffer(&hUsbDeviceFS, Buf, Len);
  result = USBD_CDC_TransmitPacket(&hUsbDeviceFS);
  /* USER CODE END 7 */
  return result;
}

further calls to Receive use the user buffer not the buffer from the CDC Interface file

no further use of RX_Buffer on sending
static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
{
  /* USER CODE BEGIN 6 */
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
  USBD_CDC_ReceivePacket(&hUsbDeviceFS);
	return (USBD_OK);
  /* USER CODE END 6 */
}

THIS IS MY PROPOSAL

All in All:

• please remove the UserRxBufferFS and UserTxBufferFS completely.
• modify the CDC_Init_FS() function as below,
• this will free as much RAM as possible.
• please note that there are requirements on that UserRxBufferFS[
  It seems the Size of the buffer is predefined and

new Init function:
static int8_t CDC_Init_FS(void)
{
  /* USER CODE BEGIN 3 */
  /* Set Application Buffers */
  USBD_CDC_SetTxBuffer(&hUsbDeviceFS, NULL, 0);
  USBD_CDC_SetRxBuffer(&hUsbDeviceFS, NULL);
  return (USBD_OK);
  /* USER CODE END 3 */
}

please note: WARNING
It is strange that Buffersize is not part of the API in USBD_CDC_SetRxBuffer() where it is in USBD_CDC_SetTxBuffer().
looking into the code in file usbd_cdc.c assumes that buffersize is as much as CDC_DATA_HS_OUT_PACKET_SIZE / CDC_DATA_FS_OUT_PACKET_SIZE.

USBD_LL_PrepareReceive(pdev, CDC_OUT_EP, hcdc->RxBuffer,
                                 CDC_DATA_HS_OUT_PACKET_SIZE);

THIS IS MY PROPOSAL

1. change the API to include buffer size.
2. create a static buffer for receive only

Describe the set-up

• STM32F411 Discovery kit
• FreeRTOS + USB Host + MSC Class + FatFs

Describe the bug
The USB driver is putting a way to much in the message queue of the OS. The OS is returning an error code that the memory can't be reserved anymore. All error codes are been ignored from the OS, that's why it is still "working".

How To Reproduce

1. Activate USBH_USE_OS
2. Set in usbh_def.h MSGQUEUE_OBJECTS to an high value. 250 for example.
3. You should see that after a while all 250 entries are been used, when an USB is connected.
4. Another way is to add in cmsis_os.c in the function of osMessagePut(...) an error reaction if xQueueSend wasn't successful.

Additional context
The USBH_Process shall only add something in the queue if really needed and if not already done.

The title says it all. Please fix the drivers so that all read-only pointers are correctly marked as const. I am sure many users will appreciate this.

Thank you.

It appears that if the output bit is set (RTC_CR_COE) it doesn't get cleared when the RTC is initialized.

In the library code:

HAL_StatusTypeDef HAL_RTC_Init(RTC_HandleTypeDef *hrtc)
{

...

else
{
/* Clear RTC_CR FMT, OSEL and POL Bits /
hrtc->Instance->CR &= ((uint32_t)~(RTC_CR_FMT | RTC_CR_OSEL | RTC_CR_POL));
/ Set RTC_CR register */
hrtc->Instance->CR |= (uint32_t)(hrtc->Init.HourFormat | hrtc->Init.OutPut | hrtc->Init.OutPutPolarity);

/* Configure the RTC PRER */
hrtc->Instance->PRER = (uint32_t)(hrtc->Init.SynchPrediv);
hrtc->Instance->PRER |= (uint32_t)(hrtc->Init.AsynchPrediv << 16U);

/* Exit Initialization mode */
hrtc->Instance->ISR &= (uint32_t)~RTC_ISR_INIT;

...

}

Should the above line be:

hrtc->Instance->CR &= ((uint32_t)~(RTC_CR_FMT | RTC_CR_OSEL | RTC_CR_POL | RTC_CR_COE));

Karl

Hello all,
Hardware PTP support seems available in ethernet enabled STM32 MCUs. Yet, there is no application note or example code available.
The only example I can find is:
https://github.com/mpthompson/stm32_f4_ptpd
Yet the boards used in this project seem obsolete and it has been 7 years since the last update.

Do you guys have a plan to include a PTP example?
Thanks.

I frequently find example code and STM32 projects on the web using HAL files or middleware like USB. None of the files include version information, and it's almost impossible to find out what specific version a developer used. As a result, it's very hard to get things working since the changes from version to version are sometimes very significant.

I suggest creating a script or batch file in your production environment, so that every time you are ready for a release, you can include version information in the header of each file (where you now have the @file name.

Lack of versioning makes it impossible to reuse old code, and it's such a simple thing to implement

I suggest to move the implementation of GPIO read/write/toggle into the header, so that the compiler (I assume GCC here) can optimize the code better without LTO. Without LTO, GCC will always insert a function call, which makes bit-banging or fast GPIO polling slower than necessary. For fast bit-banging or fast GPIO polling the overhead from the function calls actually create a measurable difference in speed.

Side note regarding LTO:

The current CubeIDE ships with a bug, so that LTO can only be used in conjunction with a workaround, I already posted about that here: https://community.st.com/s/question/0D53W00000MjO4DSAV/workaround-for-gcc-lto-bug
Unfortunately, there was no respone from ST.

In function HAL_RCC_ClockConfig, which in turn is called by SystemClockConfig and main.c from CubeMX generated code (at least when FreeRTOS is using a timer for systick)

here the default value of uwTickPrio is used, which is set (possibly by intention) to an invalid value:

This results in some unintended assertion.

In my config, TIM14 is used as the SysTick source.

My hotfix to this issue is, to set uwTickPrio to a valid value in user code section between HAL_Init and SystemClockConfig.

My installation of CubeIDE updated the firmware package to v1.25.1 today, which apparently is already a few weeks old. But there is no tag, so checking for changes since 1.25.0 is not possible here.

Is there a reason for this?

Setup

• STM32F401RE
• TrueSTUDIO
• STM32CubeF4 v1.25.2

Bug
In I2C memory mode, after the memory address has been written, the device should resend one start bit before switching to read mode. However, calling HAL_I2C_Mem_Read_IT() generates multiple start bits, resulting in the slave device answering with a NAK (see screenshot below). The event handler HAL_I2C_EV_IRQHandler() seems to be called too quickly, and the code handling the start bit is executed twice.

Fix
Incrementing EventCount in I2C_MemoryTransmit_TXE_BTF() (stm32f4xx_hal_i2c.c line 5282) prevents the start bit to be generated twice:

...

else if (hi2c->EventCount == 2U)
  {
    if (CurrentState == HAL_I2C_STATE_BUSY_RX)
    {
      /* Generate Restart */
      hi2c->Instance->CR1 |= I2C_CR1_START;
      hi2c->EventCount++;
    }
    else if ((hi2c->XferCount > 0U) && (CurrentState == HAL_I2C_STATE_BUSY_TX))

    ...

Screenshots
Before the fix:

After the fix:

USBD_SUPPORT_USER_STRING was renamed to USBD_SUPPORT_USER_STRING_DESC in version 1.25.0, but STM32CubeMX(v5.6.0) still generates USBD_SUPPORT_USER_STRING in the "usbd_conf.h" file. This will cause some problems, such as the host cannot get the memory map of the target board during DFU.

• In the "usbd_ctlreq.c" file, line 494

#if (USBD_SUPPORT_USER_STRING_DESC == 1U)
      if (pdev->pClass->GetUsrStrDescriptor != NULL)
      {
        pbuf = pdev->pClass->GetUsrStrDescriptor(pdev, (req->wValue), &len);
      }
      else
      {
        USBD_CtlError(pdev, req);
        err++;
      }
#elif (USBD_CLASS_USER_STRING_DESC == 1U)
      if (pdev->pDesc->GetUserStrDescriptor != NULL)
      {
        pbuf = pdev->pDesc->GetUserStrDescriptor(pdev->dev_speed, (req->wValue), &len);
      }
      else
      {
        USBD_CtlError(pdev, req);
        err++;
      }
#else
      USBD_CtlError(pdev, req);
      err++;
#endif

• In the "usbd_conf.h" file

/** @defgroup USBD_CONF_Exported_Defines USBD_CONF_Exported_Defines
  * @brief Defines for configuration of the Usb device.
  * @{
  */

/*---------- -----------*/
#define USBD_MAX_NUM_INTERFACES     1U
/*---------- -----------*/
#define USBD_MAX_NUM_CONFIGURATION     1U
/*---------- -----------*/
#define USBD_MAX_STR_DESC_SIZ     512U
/*---------- -----------*/
#define USBD_SUPPORT_USER_STRING     1U
/*---------- -----------*/
#define USBD_DEBUG_LEVEL     0U
/*---------- -----------*/
#define USBD_LPM_ENABLED     1U
/*---------- -----------*/
#define USBD_SELF_POWERED     1U
/*---------- -----------*/
#define USBD_DFU_MAX_ITF_NUM     1U
/*---------- -----------*/
#define USBD_DFU_XFER_SIZE     4096U
/*---------- -----------*/
#define USBD_DFU_APP_DEFAULT_ADD     0x08008000U

/****************************************/
/* #define for FS and HS identification */
#define DEVICE_FS 		0
#define DEVICE_HS 		1

/**
  * @}
  */

Thanks

Hi,

can you please add a function to create microsecond delays to the HAL, I think this would be greatly appreciated by many users.
On the internet there are implementations using the DWT module, which seems most suitable.

This likely affects not only the F4 variant, but all other STM32 families as well.

Thanks.

At stm32412g_discovery_audio.c when i am testing BSP example at ### ### \STM32Cube_FW_F4_V1.25.0\Projects\STM32F412G-Discovery\Examples\BSP
if(HAL_OK != HAL_DFSDM_FilterRegularStart_DMA(&hAudioInDfsdmFilter[POS_VAL(INPUT_DEVICE_DIGITAL_MIC1)], pScratchBuff[POS_VAL(INPUT_DEVICE_DIGITAL_MIC1)], ScratchSize)) { return AUDIO_ERROR; }
returns this error return AUDIO_ERROR;
and moments later i got at this function}

*/
void HardFault_Handler(void)
{
 /* Go to infinite loop when Hard Fault exception occurs */
 while (1)
 {
 }
}

I am working with stm32f412-discovery board.

It's over a week.
I test that the STM32F407 Discovery working as receiver is ok (no any transmit function like HAL_SPI_Transmit or HAL_SPI_TransmitReceive).
But after I added the transmit function for the purpose to send data to Master, it does not work correctly.
I described the issue in the video below.
Hope to receive your help.
Thank you so much.

https://www.youtube.com/watch?v=xA6N_trzkb0

If you generate a project with USB CDC via CubeMX, the following variable and respective logic is missing from usbd_cdc_if.c:

I tested this with version 1.25.2. I think this might affect other repos as well.

The following declaration wastes 448 Byte of RAM on all devices where CDC is used with a USB FS spec.

The documentation suggests you could modify CDC_DATA_HS_MAX_PACKET_SIZE but that would only be a workaround.

Possible fix:

typedef struct
{
#ifdef USBD_NO_HS          /* can be set by cubeMX or provided by user as project configuration */
   uint32_t data[CDC_DATA_FS_MAX_PACKET_SIZE / 4U];      /* Force 32bits alignment */
#else
   uint32_t data[CDC_DATA_HS_MAX_PACKET_SIZE / 4U];      /* Force 32bits alignment */
#endif

One could also query the #define USE_USB_FS which is used in usbd_core.c .

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 board with STM32F412CG.
Mbed OS 6.2.0 with GCC ARM 9-2020-q2-update

Describe the bug
Cannot link serial_api, since there is a contradiction between CMSIS and HAL:

In CMSIS stm32f412cx.h USART3_BASE is defined.

In RCC HAL, USART3 functions are not defined for STM32F412Cx.

This causes linker issues for example when trying to link serial_api.o of the STM HAL in Mbed OS due to these lines:

https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/serial_api.c#L246-L252

I believe this is not an Mbed issue but an HAL issue.

How To Reproduce
Try to build an Mbed OS 6.2.0 project for STM32F412CG.

Additional context
It is fixed when STM32F412Cx is added to the conditions for all USART3 functions.

Screenshots
N.a.

STM32F411E-DISCO
STM32CubeIDE Version: 1.2.1 Build: 5190_20200115_1224 (UTC)

When I was using HAL_I2C_Mem_Read when I detected problem with I2C_RequestMemoryRead.
I2C_RequestMemoryRead always returned HAL_ERROR.
When I was creating new project I changed frimware version for F411 from 1.24.2 to 1.24.0.
This action fixed this issue.

How To Reproduce

1. Indicate the global behavior of your application project.
   I have no I2C communiction.

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

3. The use case that generates the problem.
   Communication by i2c with LSM303DLHC on discovery board.
   Use HAL_I2C_Mem_Read - this function always returns HAL_ERROR

4. How we can reproduce the problem.
   Generate project in CubeIDE for LSM303 communication. Use HAL_I2C_Mem_Read form 1.24.2 firmware version.

If the input length is not a multiple of 4, the function overruns the buffer by 3, 2 or 1 byte.
This could trigger an exception (HardFault/BusFault), e.g. if one passes a buffer pointing to the last byte in RAM and length=1.

Other devices are possible affected as well.

Incorrect bracing in the sd_read and sd_write functions cause memory access alignment crashes when ENABLE_SCRATCH_BUFFER is enabled.

Additionally the memcpy is incorrect, copying data in the wrong direction int the write function.

I posted information about this in the forum linked

https://community.st.com/s/question/0D50X0000ArVPjuSQG/hal-bug-sddiskiodmatemplate-in-stm32cubefwf4v1241

As pull requests are not currently activated, I've fixed the issue and the code is attached in the .txt file.

fixed.txt

orig.txt

I've attached the original code too, so a simple diff will reveal the code changes.

These problems also exist in the F7 library, I've not checked others.

A checkout of this git repository takes up about 1.4 GB on disk, and cloning it pulls about 150 MB across the net. Most of this disk and bandwidth is comprised of the example projects, as well as some particularly large documentation files. There are also some files that seem somewhat unecessary like this 2 MB bitmap image, and this 26 MB of audio files that will be very infrequently used.

We would like to use this repository as a git submodule within our firmware projects, but this causes problems:

• Every firmware project we have would take up 1.4 GB on disk, so we'd waste quite a lot of disk space.
• Our CI pipeline builds will be slowed down by using it. On a fast connection (Linode box) it currently takes about 12 seconds to pull this repository across the net, and then another 10 seconds to actually unpack it onto disk. Adding 22s to every CI build slows us down.

Our workaround at the moment is to make a repository of our own with the same structure as this one, with all the extra stuff removed. This brings the repository size down significantly (to about 11 MB, which takes less than a second to pull across the network), but comes at the expense of making it harder to upgrade to a later version of STM32CubeF4, as we have to go through that process every time.

Please will you consider splitting this repository up into several repositories -- I imagine at least this set:

• The minimal source for building against (presumably most things in Drivers -- the things in Middlewares would presumably be better suited in a separate repository anyway, as they are presumably replicated in other STM32CubeF* instances too...)
• An examples repository
• Potentially a documentation repository

Describe the set-up

• The board: nucleo_f446ze
• IDE: vscode+platformio+stm32cube framework
• Extra lib: STM32Cube Middleware-FreeRTOS

Describe the bug
I setup uart3 for a baudrate of 115200, but I get a baudrate of 38400.
Also SystemCoreClock= 525000000. Which is clearly wrong.

How To Reproduce

1. create a project in stm32cubemx. I setup uart3 and other uarts + USB.

2. generate code using these settings: https://github.com/ussserrr/stm32pio#example

3. copy all the generated source files to lib/stm/src. Test uart printing:

uint8_t hewo[]= "Hello world!\r\n";
HAL_UART_Transmit(&huart3,hewo,sizeof(hewo)-1,10000);
vTaskDelay(500);

4. I get non-ascii characters at 115200 baud and get Hello world! at 38400 baud. Debugging shows crazy values for pll such as pllvco=1050000000 and SystemCoreClock= 525000000. The parameters seem to match the clock configuration.

Contents of my .ioc-file:

#MicroXplorer Configuration settings - do not modify
File.Version=6
KeepUserPlacement=false
Mcu.Family=STM32F4
Mcu.IP0=NVIC
Mcu.IP1=RCC
Mcu.IP10=USB_OTG_FS
Mcu.IP2=SYS
Mcu.IP3=UART4
Mcu.IP4=UART5
Mcu.IP5=USART1
Mcu.IP6=USART2
Mcu.IP7=USART3
Mcu.IP8=USART6
Mcu.IP9=USB_DEVICE
Mcu.IPNb=11
Mcu.Name=STM32F446Z(C-E)Tx
Mcu.Package=LQFP144
Mcu.Pin0=PC13
Mcu.Pin1=PC14-OSC32_IN
Mcu.Pin10=PD8
Mcu.Pin11=PD9
Mcu.Pin12=PG6
Mcu.Pin13=PG7
Mcu.Pin14=PC6
Mcu.Pin15=PA8
Mcu.Pin16=PA9
Mcu.Pin17=PA10
Mcu.Pin18=PA11
Mcu.Pin19=PA12
Mcu.Pin2=PC15-OSC32_OUT
Mcu.Pin20=PA13
Mcu.Pin21=PA14
Mcu.Pin22=PB6
Mcu.Pin23=PB7
Mcu.Pin24=VP_SYS_VS_Systick
Mcu.Pin25=VP_USB_DEVICE_VS_USB_DEVICE_CDC_FS
Mcu.Pin3=PH0-OSC_IN
Mcu.Pin4=PH1-OSC_OUT
Mcu.Pin5=PA0-WKUP
Mcu.Pin6=PA2
Mcu.Pin7=PB0
Mcu.Pin8=PE8
Mcu.Pin9=PB14
Mcu.PinsNb=26
Mcu.ThirdPartyNb=0
Mcu.UserConstants=
Mcu.UserName=STM32F446ZETx
MxCube.Version=5.6.0
MxDb.Version=DB.5.0.60
NVIC.BusFault_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.DebugMonitor_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.ForceEnableDMAVector=true
NVIC.HardFault_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.MemoryManagement_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.NonMaskableInt_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.OTG_FS_IRQn=true\:0\:0\:false\:false\:true\:false\:true
NVIC.PendSV_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.PriorityGroup=NVIC_PRIORITYGROUP_4
NVIC.SVCall_IRQn=true\:0\:0\:false\:false\:true\:true\:false
NVIC.SysTick_IRQn=true\:0\:0\:false\:false\:true\:true\:true
NVIC.UsageFault_IRQn=true\:0\:0\:false\:false\:true\:true\:false
PA0-WKUP.Mode=Half_duplex(single_wire_mode)
PA0-WKUP.Signal=UART4_TX
PA10.GPIOParameters=GPIO_Label
PA10.GPIO_Label=USB_ID
PA10.Locked=true
PA10.Signal=USB_OTG_FS_ID
PA11.GPIOParameters=GPIO_Label
PA11.GPIO_Label=USB_DM
PA11.Locked=true
PA11.Mode=Device_Only
PA11.Signal=USB_OTG_FS_DM
PA12.GPIOParameters=GPIO_Label
PA12.GPIO_Label=USB_DP
PA12.Locked=true
PA12.Mode=Device_Only
PA12.Signal=USB_OTG_FS_DP
PA13.GPIOParameters=GPIO_Label
PA13.GPIO_Label=TMS
PA13.Locked=true
PA13.Mode=Serial_Wire
PA13.Signal=SYS_JTMS-SWDIO
PA14.GPIOParameters=GPIO_Label
PA14.GPIO_Label=TCK
PA14.Locked=true
PA14.Mode=Serial_Wire
PA14.Signal=SYS_JTCK-SWCLK
PA2.Mode=Half_duplex(single_wire_mode)
PA2.Signal=USART2_TX
PA8.GPIOParameters=GPIO_Label
PA8.GPIO_Label=USB_SOF [TP1]
PA8.Locked=true
PA8.Mode=Activate_SOF_FS
PA8.Signal=USB_OTG_FS_SOF
PA9.GPIOParameters=GPIO_Label
PA9.GPIO_Label=USB_VBUS
PA9.Locked=true
PA9.Mode=Activate_VBUS
PA9.Signal=USB_OTG_FS_VBUS
PB0.GPIOParameters=GPIO_Label
PB0.GPIO_Label=LD1 [Green]
PB0.Locked=true
PB0.Signal=GPIO_Output
PB14.GPIOParameters=GPIO_Label
PB14.GPIO_Label=LD3 [Red]
PB14.Locked=true
PB14.Signal=GPIO_Output
PB6.Mode=Half_duplex(single_wire_mode)
PB6.Signal=USART1_TX
PB7.GPIOParameters=GPIO_Label
PB7.GPIO_Label=LD2 [Blue]
PB7.Locked=true
PB7.Signal=GPIO_Output
PC13.GPIOParameters=GPIO_Label
PC13.GPIO_Label=USER_Btn [B1]
PC13.Locked=true
PC13.Signal=GPXTI13
PC14-OSC32_IN.Locked=true
PC14-OSC32_IN.Mode=LSE-External-Oscillator
PC14-OSC32_IN.Signal=RCC_OSC32_IN
PC15-OSC32_OUT.Locked=true
PC15-OSC32_OUT.Mode=LSE-External-Oscillator
PC15-OSC32_OUT.Signal=RCC_OSC32_OUT
PC6.Mode=Half_duplex(single_wire_mode)
PC6.Signal=USART6_TX
PD8.GPIOParameters=GPIO_Label
PD8.GPIO_Label=STLK_RX [STM32F103CBT6_PA3]
PD8.Locked=true
PD8.Mode=Asynchronous
PD8.Signal=USART3_TX
PD9.GPIOParameters=GPIO_Label
PD9.GPIO_Label=STLK_TX [STM32F103CBT6_PA2]
PD9.Locked=true
PD9.Mode=Asynchronous
PD9.Signal=USART3_RX
PE8.Mode=Half_duplex(single_wire_mode)
PE8.Signal=UART5_TX
PG6.GPIOParameters=GPIO_Label
PG6.GPIO_Label=USB_PowerSwitchOn [STMPS2151STR_EN]
PG6.Locked=true
PG6.Signal=GPIO_Output
PG7.GPIOParameters=GPIO_Label
PG7.GPIO_Label=USB_OverCurrent [STMPS2151STR_FAULT]
PG7.Locked=true
PG7.Signal=GPIO_Input
PH0-OSC_IN.GPIOParameters=GPIO_Label
PH0-OSC_IN.GPIO_Label=MCO [STM32F103CBT6_PA8]
PH0-OSC_IN.Locked=true
PH0-OSC_IN.Mode=HSE-External-Clock-Source
PH0-OSC_IN.Signal=RCC_OSC_IN
PH1-OSC_OUT.Locked=true
PH1-OSC_OUT.Mode=HSE-External-Clock-Source
PH1-OSC_OUT.Signal=RCC_OSC_OUT
PinOutPanel.RotationAngle=0
ProjectManager.AskForMigrate=true
ProjectManager.BackupPrevious=false
ProjectManager.CompilerOptimize=6
ProjectManager.ComputerToolchain=false
ProjectManager.CoupleFile=true
ProjectManager.CustomerFirmwarePackage=
ProjectManager.DefaultFWLocation=true
ProjectManager.DeletePrevious=true
ProjectManager.DeviceId=STM32F446ZETx
ProjectManager.FirmwarePackage=STM32Cube FW_F4 V1.25.0
ProjectManager.FreePins=true
ProjectManager.HalAssertFull=false
ProjectManager.HeapSize=0x200
ProjectManager.KeepUserCode=true
ProjectManager.LastFirmware=true
ProjectManager.LibraryCopy=1
ProjectManager.MainLocation=Src
ProjectManager.NoMain=false
ProjectManager.PreviousToolchain=
ProjectManager.ProjectBuild=false
ProjectManager.ProjectFileName=stm_serial3.ioc
ProjectManager.ProjectName=stm_serial3
ProjectManager.StackSize=0x400
ProjectManager.TargetToolchain=Other Toolchains (GPDSC)
ProjectManager.ToolChainLocation=
ProjectManager.UnderRoot=false
ProjectManager.functionlistsort=1-MX_GPIO_Init-GPIO-false-HAL-true,2-SystemClock_Config-RCC-false-HAL-false,3-MX_UART4_Init-UART4-false-HAL-true,4-MX_UART5_Init-UART5-false-HAL-true,5-MX_USART1_UART_Init-USART1-false-HAL-true,6-MX_USART2_UART_Init-USART2-false-HAL-true,7-MX_USART3_UART_Init-USART3-false-HAL-true,8-MX_USART6_UART_Init-USART6-false-HAL-true,9-MX_USB_DEVICE_Init-USB_DEVICE-false-HAL-false
RCC.48MHZClocksFreq_Value=24000000
RCC.ADC12outputFreq_Value=72000000
RCC.ADC34outputFreq_Value=72000000
RCC.AHBFreq_Value=168000000
RCC.APB1CLKDivider=RCC_HCLK_DIV4
RCC.APB1Freq_Value=42000000
RCC.APB1TimFreq_Value=84000000
RCC.APB2CLKDivider=RCC_HCLK_DIV2
RCC.APB2Freq_Value=84000000
RCC.APB2TimFreq_Value=168000000
RCC.CECFreq_Value=32786.88524590164
RCC.CortexFreq_Value=168000000
RCC.EthernetFreq_Value=8000000
RCC.FCLKCortexFreq_Value=168000000
RCC.FMPI2C1Freq_Value=42000000
RCC.FamilyName=M
RCC.HCLKFreq_Value=168000000
RCC.HSE_VALUE=8000000
RCC.HSI_VALUE=16000000
RCC.I2C1Freq_Value=8000000
RCC.I2C2Freq_Value=8000000
RCC.I2C3Freq_Value=8000000
RCC.I2S1Freq_Value=48000000
RCC.I2S2Freq_Value=48000000
RCC.I2SClocksFreq_Value=48000000
RCC.IPParameters=48MHZClocksFreq_Value,ADC12outputFreq_Value,ADC34outputFreq_Value,AHBFreq_Value,APB1CLKDivider,APB1Freq_Value,APB1TimFreq_Value,APB2CLKDivider,APB2Freq_Value,APB2TimFreq_Value,CECFreq_Value,CortexFreq_Value,EthernetFreq_Value,FCLKCortexFreq_Value,FMPI2C1Freq_Value,FamilyName,HCLKFreq_Value,HSE_VALUE,HSI_VALUE,I2C1Freq_Value,I2C2Freq_Value,I2C3Freq_Value,I2S1Freq_Value,I2S2Freq_Value,I2SClocksFreq_Value,LCDTFTFreq_Value,LSI_VALUE,MCO1PinFreq_Value,MCO2PinFreq_Value,MCOFreq_Value,PLLCLKFreq_Value,PLLI2SPCLKFreq_Value,PLLI2SQCLKFreq_Value,PLLI2SRCLKFreq_Value,PLLI2SoutputFreq_Value,PLLM,PLLMCOFreq_Value,PLLMUL,PLLN,PLLQ,PLLQCLKFreq_Value,PLLRCLKFreq_Value,PLLSAIPCLKFreq_Value,PLLSAIQCLKFreq_Value,PLLSAIoutputFreq_Value,PRESCALERUSB,PWRFreq_Value,RTCFreq_Value,RTCHSEDivFreq_Value,SAIAFreq_Value,SAIBFreq_Value,SAI_AClocksFreq_Value,SAI_BClocksFreq_Value,SDIOFreq_Value,SPDIFRXFreq_Value,SYSCLKFreq_VALUE,SYSCLKSource,SYSCLKSourceVirtual,TIM15Freq_Value,TIM16Freq_Value,TIM17Freq_Value,TIM1Freq_Value,TIM20Freq_Value,TIM2Freq_Value,TIM3Freq_Value,TIM8Freq_Value,UART4Freq_Value,UART5Freq_Value,USART1Freq_Value,USART2Freq_Value,USART3Freq_Value,USBFreq_Value,VCOI2SInputFreq_Value,VCOI2SOutputFreq_Value,VCOInputFreq_Value,VCOOutput2Freq_Value,VCOOutputFreq_Value,VCOSAIInputFreq_Value,VCOSAIOutputFreq_Value,VCOSAIOutputFreq_ValueQ,VCOSAIOutputFreq_ValueR,VcooutputI2S,VcooutputI2SQ,WatchDogFreq_Value
RCC.LCDTFTFreq_Value=6125000
RCC.LSI_VALUE=32000
RCC.MCO1PinFreq_Value=16000000
RCC.MCO2PinFreq_Value=168000000
RCC.MCOFreq_Value=72000000
RCC.PLLCLKFreq_Value=168000000
RCC.PLLI2SPCLKFreq_Value=48000000
RCC.PLLI2SQCLKFreq_Value=48000000
RCC.PLLI2SRCLKFreq_Value=48000000
RCC.PLLI2SoutputFreq_Value=48000000
RCC.PLLM=4
RCC.PLLMCOFreq_Value=72000000
RCC.PLLMUL=RCC_PLL_MUL9
RCC.PLLN=168
RCC.PLLQ=7
RCC.PLLQCLKFreq_Value=48000000
RCC.PLLRCLKFreq_Value=168000000
RCC.PLLSAIPCLKFreq_Value=48000000
RCC.PLLSAIQCLKFreq_Value=48000000
RCC.PLLSAIoutputFreq_Value=48000000
RCC.PRESCALERUSB=RCC_USBCLKSOURCE_PLL_DIV1_5
RCC.PWRFreq_Value=168000000
RCC.RTCFreq_Value=32000
RCC.RTCHSEDivFreq_Value=4000000
RCC.SAIAFreq_Value=48000000
RCC.SAIBFreq_Value=48000000
RCC.SAI_AClocksFreq_Value=6125000
RCC.SAI_BClocksFreq_Value=6125000
RCC.SDIOFreq_Value=48000000
RCC.SPDIFRXFreq_Value=168000000
RCC.SYSCLKFreq_VALUE=168000000
RCC.SYSCLKSource=RCC_SYSCLKSOURCE_PLLCLK
RCC.SYSCLKSourceVirtual=RCC_SYSCLKSOURCE_PLLCLK
RCC.TIM15Freq_Value=72000000
RCC.TIM16Freq_Value=72000000
RCC.TIM17Freq_Value=72000000
RCC.TIM1Freq_Value=72000000
RCC.TIM20Freq_Value=72000000
RCC.TIM2Freq_Value=72000000
RCC.TIM3Freq_Value=72000000
RCC.TIM8Freq_Value=72000000
RCC.UART4Freq_Value=36000000
RCC.UART5Freq_Value=36000000
RCC.USART1Freq_Value=72000000
RCC.USART2Freq_Value=36000000
RCC.USART3Freq_Value=36000000
RCC.USBFreq_Value=48000000
RCC.VCOI2SInputFreq_Value=500000
RCC.VCOI2SOutputFreq_Value=96000000
RCC.VCOInputFreq_Value=2000000
RCC.VCOOutput2Freq_Value=8000000
RCC.VCOOutputFreq_Value=336000000
RCC.VCOSAIInputFreq_Value=500000
RCC.VCOSAIOutputFreq_Value=96000000
RCC.VCOSAIOutputFreq_ValueQ=6125000
RCC.VCOSAIOutputFreq_ValueR=12250000
RCC.VcooutputI2S=48000000
RCC.VcooutputI2SQ=48000000
RCC.WatchDogFreq_Value=32000
SH.GPXTI13.0=GPIO_EXTI13
SH.GPXTI13.ConfNb=1
UART4.BaudRate=2000000
UART4.IPParameters=VirtualMode,BaudRate
UART4.VirtualMode=Asynchronous
UART5.BaudRate=2000000
UART5.IPParameters=VirtualMode,BaudRate
UART5.VirtualMode=Asynchronous
USART1.BaudRate=2000000
USART1.IPParameters=VirtualMode,BaudRate
USART1.VirtualMode=VM_ASYNC
USART2.BaudRate=2000000
USART2.IPParameters=VirtualMode,BaudRate
USART2.VirtualMode=VM_ASYNC
USART3.IPParameters=VirtualMode
USART3.VirtualMode=VM_ASYNC
USART6.BaudRate=2000000
USART6.IPParameters=VirtualMode,BaudRate
USART6.VirtualMode=VM_ASYNC
USB_DEVICE.CLASS_NAME_FS=CDC
USB_DEVICE.IPParameters=VirtualMode-CDC_FS,VirtualModeFS,CLASS_NAME_FS,MANUFACTURER_STRING-CDC_FS,PRODUCT_STRING_CDC_FS
USB_DEVICE.MANUFACTURER_STRING-CDC_FS=Electron Square
USB_DEVICE.PRODUCT_STRING_CDC_FS=Electron Square tty
USB_DEVICE.VirtualMode-CDC_FS=Cdc
USB_DEVICE.VirtualModeFS=Cdc_FS
USB_OTG_FS.IPParameters=VirtualMode
USB_OTG_FS.VirtualMode=Device_Only
VP_SYS_VS_Systick.Mode=SysTick
VP_SYS_VS_Systick.Signal=SYS_VS_Systick
VP_USB_DEVICE_VS_USB_DEVICE_CDC_FS.Mode=CDC_FS
VP_USB_DEVICE_VS_USB_DEVICE_CDC_FS.Signal=USB_DEVICE_VS_USB_DEVICE_CDC_FS
board=NUCLEO-F446ZE
boardIOC=true

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.
  If one generate project with lwip middleware, it is possible to specify IP address and MAC address in the CubeMX IDE.
  However noone would generate 1(one) CubeMX project per device in order to setup different IP Addresses per device.
  Instead the generated code should support some kind of user customization to allow per device addresses.

Describe the bug
A clear and concise description of what the bug is.

For IP address the code in lwip is
`
void MX_LWIP_Init(void)
{
/* IP addresses initialization */
IP_ADDRESS[0] = 192;
IP_ADDRESS[1] = 168;
IP_ADDRESS[2] = 123;
IP_ADDRESS[3] = 3;
NETMASK_ADDRESS[0] = 255;
NETMASK_ADDRESS[1] = 255;
NETMASK_ADDRESS[2] = 255;
NETMASK_ADDRESS[3] = 0;
GATEWAY_ADDRESS[0] = 0;
GATEWAY_ADDRESS[1] = 0;
GATEWAY_ADDRESS[2] = 0;
GATEWAY_ADDRESS[3] = 0;

/* Initilialize the LwIP stack without RTOS */
lwip_init();

/* IP addresses initialization without DHCP (IPv4) */
IP4_ADDR(&ipaddr, IP_ADDRESS[0], IP_ADDRESS[1], IP_ADDRESS[2], IP_ADDRESS[3]);
IP4_ADDR(&netmask, NETMASK_ADDRESS[0], NETMASK_ADDRESS[1] , NETMASK_ADDRESS[2], NETMASK_ADDRESS[3]);
IP4_ADDR(&gw, GATEWAY_ADDRESS[0], GATEWAY_ADDRESS[1], GATEWAY_ADDRESS[2], GATEWAY_ADDRESS[3]);

/* add the network interface (IPv4/IPv6) without RTOS */
netif_add(&gnetif, &ipaddr, &netmask, &gw, NULL, &ethernetif_init, &ethernet_input);

/* Registers the default network interface */
netif_set_default(&gnetif);

if (netif_is_link_up(&gnetif))
{
/* When the netif is fully configured this function must be called /
netif_set_up(&gnetif);
}
else
{
/ When the netif link is down this function must be called */
netif_set_down(&gnetif);
}

/* Set the link callback function, this function is called on change of link status*/
netif_set_link_callback(&gnetif, ethernetif_update_config);

/* Create the Ethernet link handler thread */

/* USER CODE BEGIN 3 /
ethernetif_notify_conn_changed(&gnetif);
/ USER CODE END 3 */
}
`
As you see there thee is straight code section from the beginning until the end with no USER CODE BEGIN/END.

For MAC Address the generated code lookes like this ethernetif.c:
please note that I (the user) can customize the MAC address per device
static void low_level_init(struct netif *netif)
{
HAL_StatusTypeDef hal_eth_init_status;

/* Init ETH */

uint8_t MACAddr[6] ;
heth.Instance = ETH;
heth.Init.AutoNegotiation = ETH_AUTONEGOTIATION_ENABLE;
heth.Init.PhyAddress = PHY_KSZ8081_PHY_ADDRESS;
MACAddr[0] = 0x00;
MACAddr[1] = 0x80;
MACAddr[2] = 0xE1;
MACAddr[3] = 0x00;
MACAddr[4] = 0x00;
MACAddr[5] = 0x00;
heth.Init.MACAddr = &MACAddr[0];
heth.Init.RxMode = ETH_RXPOLLING_MODE;
heth.Init.ChecksumMode = ETH_CHECKSUM_BY_HARDWARE;
heth.Init.MediaInterface = ETH_MEDIA_INTERFACE_MII;

/* USER CODE BEGIN MACADDRESS */
// assert the phy reset line for 5msec
HAL_GPIO_WritePin(ETH_RST_L_GPIO_Port, ETH_RST_L_Pin, GPIO_PIN_RESET);
HAL_Delay(5);
HAL_GPIO_WritePin(ETH_RST_L_GPIO_Port, ETH_RST_L_Pin, GPIO_PIN_SET);
HAL_Delay(5);

memcpy(MACAddr, app_ctx.mac_address, 6);

/* USER CODE END MACADDRESS */

hal_eth_init_status = HAL_ETH_Init(&heth);
...
`
Currently all my customization is lost after regenerating the project.

as a solution I recommend to insert an other USER CODE section in the lwip.c like this before lwip_init():
For IP address the code in lwip is
`
void MX_LWIP_Init(void)
{
/* IP addresses initialization */
IP_ADDRESS[0] = 192;
IP_ADDRESS[1] = 168;
IP_ADDRESS[2] = 123;
IP_ADDRESS[3] = 3;
NETMASK_ADDRESS[0] = 255;
NETMASK_ADDRESS[1] = 255;
NETMASK_ADDRESS[2] = 255;
NETMASK_ADDRESS[3] = 0;
GATEWAY_ADDRESS[0] = 0;
GATEWAY_ADDRESS[1] = 0;
GATEWAY_ADDRESS[2] = 0;
GATEWAY_ADDRESS[3] = 0;

/* USER CODE END IPADDRESS /
/ USER CODE END IPADDRESS */

/* Initilialize the LwIP stack without RTOS */
lwip_init();

/* IP addresses initialization without DHCP (IPv4) */
IP4_ADDR(&ipaddr, IP_ADDRESS[0], IP_ADDRESS[1], IP_ADDRESS[2], IP_ADDRESS[3]);
IP4_ADDR(&netmask, NETMASK_ADDRESS[0], NETMASK_ADDRESS[1] , NETMASK_ADDRESS[2], NETMASK_ADDRESS[3]);
IP4_ADDR(&gw, GATEWAY_ADDRESS[0], GATEWAY_ADDRESS[1], GATEWAY_ADDRESS[2], GATEWAY_ADDRESS[3]);

/* add the network interface (IPv4/IPv6) without RTOS */
netif_add(&gnetif, &ipaddr, &netmask, &gw, NULL, &ethernetif_init, &ethernet_input);
...
`

This way also IP Address is customizable by user.

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.

Describe the set-up
I am using the NUCLEO-F411RE and System Workbench (AC6) and your uart print project

Describe the bug
There is no .cfg file for the board I am using even tho it specifies that the project is specifically for the IDE. I found a .cfg file for my nucleo and now it works, but you should provide one so that the user has the debug configuration out of the box.

How To Reproduce

1. Checkout your code.
2. Try to debug it or load it onto the processor

STM32CubeMX
(OS: Windows 10)

Target: F405
Enabled USB_OTG_FS & USB_DEVICE (VIRTUAL_PORT)
File: %project%\USB_DEVICE\App\usbd_cdc_if.c
Line: 255 (brief of CDC_Receive_FS fun.)
"untill exiting this function. If you exit this function before transfer"

double l in "utilll"

I am using CubeMX v6.1.1 with CubeF4 v1.25.2 to generate code for STM32F412CGUx with STM32CubeIDE.

The app generates usbd_conf.c with following function included:

/**
  * @brief  Handle USB VBUS detection upon external interrupt
  * @param  GPIO_Pin
  * @retval None
  */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
  if (GPIO_Pin == GPIO_PIN_9)
  {
    HAL_PCDEx_BCD_VBUSDetect(&hpcd_USB_OTG_FS);
  }
}

This causes linkage errors when there is a user-implemented EXTI Callback.
The issue happens regardless of VBUS Sensing setting in CubeMX - even when it is off, the callback still gets generated (not saying it should be generated that way when VBUS Sensing is on).

This was reproducible with STM32F412RE but NOT with STM32F446RE or STM32F411CEUx

Please see generated files attached: stm32f412-usb-vbus-off.zip

USB settings used: