stmicroelectronics / stm32l4xx_hal_driver

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

STM32CubeL4 HAL Driver MCU Component

Overview

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

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

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

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

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

Description

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

Release note

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

Compatibility information

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

The full STM32CubeL4 MCU package is available here.

Troubleshooting

Please refer to the CONTRIBUTING.md guide.

stm32l4xx_hal_driver's Issues

Compatibility information missing for v1.13.4

The Compatibility information table in the README is missing the set of versions to use with the latest release tag (v1.13.4).
Could you please add it?

It seems that STM32L476 is capable for 4-bit SD/MMC bus, but it's not supported.

Describe the set-up

I'm using a NUCLEO-L476RG with Zephyr (f51c8ee739).

Describe the bug

While trying to use a 4-bit SD/MMC bus, the system locks up... when using 1-bit bus the system works fine.

On investigation, it seems that this driver will never communicate the changed bus width with the card, resulting in a breakdown in stm32_sdmmc_access_read().

• Am I correct in thinking that the STM32L476 should indeed support 4-bit mode?
• Why are only a subset of parts calling HAL_SD_ConfigWideBusOperation()?

How To Reproduce

• Connect an SD card to the NUCLEO board
  • CLK -> PC12 (CN7.3)
  • CMD -> PD2 (CN7.4)
  • D0 -> PC8 (CN10.2)
  • D1 -> PC9 (CN10.1)
  • D2 -> PC10 (CN7.1)
  • D3 -> PC11 (CN7.2)
• Checkout Zephyr & dependencies
• Amend the .../samples/subsys/shell/shell_module/prj.conf as below.
• Add the below board file to .../samples/subsys/shell/shell_module/boards/
• Build the sample:
  • cmake -GNinja -S ./zephyr/samples/subsys/shell/shell_module/ -B ./sdmmc_repro -DBOARD=nucleo_l476rg -DCONFIG_LOG_MODE_IMMEDIATE=y
  • ninja -C ./sdmmc_repro/
  • st-flash --reset --connect-under-reset write ./sdmmc_repro/zephyr/zephyr.bin 0x08000000
• A the Zephyr shell prompt, run fs mount fat /SD:, and note that the system "hangs"

`.../samples/subsys/shell/shell_module/prj.conf`

diff --git samples/subsys/shell/shell_module/prj.conf samples/subsys/shell/shell_module/prj.conf
index 41d51f8e22..98567901fd 100644
--- samples/subsys/shell/shell_module/prj.conf
+++ samples/subsys/shell/shell_module/prj.conf
@@ -1,5 +1,6 @@
 CONFIG_PRINTK=y
 CONFIG_SHELL=y
+CONFIG_SHELL_STACK_SIZE=16384
 CONFIG_LOG=y
 CONFIG_LOG_CMDS=y
 CONFIG_INIT_STACKS=y
@@ -15,3 +16,24 @@ CONFIG_THREAD_RUNTIME_STATS=y
 CONFIG_THREAD_RUNTIME_STATS_USE_TIMING_FUNCTIONS=y
 CONFIG_STATS=y
 CONFIG_STATS_SHELL=y
+
+CONFIG_HEAP_MEM_POOL_SIZE=8192
+
+CONFIG_I2C=y
+CONFIG_I2C_SHELL=y
+
+CONFIG_DISK_DRIVERS=y
+CONFIG_DISK_DRIVER_SDMMC=y
+CONFIG_SDHC=y
+CONFIG_FILE_SYSTEM=y
+CONFIG_FILE_SYSTEM_SHELL=y
+CONFIG_FILE_SYSTEM_SHELL_TEST_COMMANDS=y
+CONFIG_FILE_SYSTEM_SHELL_BUFFER_SIZE=0x2000
+CONFIG_FAT_FILESYSTEM_ELM=y
+CONFIG_FS_FATFS_MOUNT_MKFS=n
+CONFIG_FS_FATFS_EXFAT=y
+
+CONFIG_CAN=y
+CONFIG_CAN_SHELL=y
+
+CONFIG_GPIO_SHELL=y

`.../samples/subsys/shell/shell_module/boards/nucleo_l476rg.overlay`

/delete-node/ &spi3;
&sdmmc1 {
       bus-width = <4>;
       clk-div = <0>;
       pinctrl-0 = <
               &sdmmc1_ck_pc12
               &sdmmc1_cmd_pd2
               &sdmmc1_d0_pc8
               &sdmmc1_d1_pc9
               &sdmmc1_d2_pc10
               &sdmmc1_d3_pc11
       >;
       pinctrl-names = "default";
       status = "okay";
};

&clk_msi {
       msi-range = <11>; /* ~48 MHz */
       status = "okay";
};

Incorrect STM32L4P5xx and STM32L4Q5xx RNG Initialisation in Low Level API

In a post here https://community.st.com/t5/stm32-mcus-security/why-am-i-getting-an-rng-failure-on-the-stm32l4p5/m-p/203250. It was recognised that the HAL was initialising the RNG peripheral incorrectly.

The HAL function HAL_RNG_Init seems to have been corrected to set the correct CONFIG[1,2,3] and HTCR.

However the LL version of this function doesn't include any of this, so the CONFIG[1,2,3] and HTCR will all contain the wrong values when using this function.

stm32l4xx_hal_driver/Src/stm32l4xx_ll_rng.c

Lines 118 to 135 in eb4b2d2

	ErrorStatus LL_RNG_Init(RNG_TypeDef *RNGx, LL_RNG_InitTypeDef *RNG_InitStruct)
	{
	/* Check the parameters */
	assert_param(IS_RNG_ALL_INSTANCE(RNGx));
	assert_param(IS_LL_RNG_CED(RNG_InitStruct->ClockErrorDetection));
	#if defined(RNG_CR_CONDRST)
	/* Clock Error Detection Configuration when CONDRT bit is set to 1 */
	MODIFY_REG(RNGx->CR, RNG_CR_CED | RNG_CR_CONDRST, RNG_InitStruct->ClockErrorDetection | RNG_CR_CONDRST);
	/* Writing bits CONDRST=0*/
	CLEAR_BIT(RNGx->CR, RNG_CR_CONDRST);
	#else
	/* Clock Error Detection configuration */
	MODIFY_REG(RNGx->CR, RNG_CR_CED, RNG_InitStruct->ClockErrorDetection);
	#endif /* RNG_CR_CONDRST */
	return (SUCCESS);
	}

Could this function be updated to set the correct values, as described in Table 225. RNG configurations
of RM0432?

`HAL_I2C_Master_Transmit` timeout parameter behaves unexpectedly

Describe the set-up

• The board (either ST RPN reference or your custom board)
  • STM32L4P5AG-DK
• IDE or at least the compiler and its version
  • STM32CubeIDE Version: 1.4.0
  • Build: 7511_20200720_0928 (UTC)

Describe the bug
The timeout parameter begins counting from the instant the transaction begins, and it doesn't appear that the watchdog is being reset with each incoming byte. Therefore, when you have a long I2C transaction, it will timeout, even if it is working perfectly.

Here is an example with a 250ms timeout:

Invocation:
HAL_I2C_Master_Transmit(&hi2c4, (dev_addr << 1), query_request, strlen(query_request), 250);

How To Reproduce

1. Select a slow I2C speed (i.e. 100kHz).
2. Select a easy timeout value that is easy to test (e.g. 100ms).
3. Send a long I2C transaction that is guaranteed to surpass the given timeout.
4. The transaction will stop sending midstream, within a few milliseconds of the timeout expiration.
5. I assume this is isolated to the I2C Timeout watchdog

Expected Behavior
I would expect the timeout to be related to the amount of time the slave device holds the line low, or time between incoming bytes, but certainly not the length of an in progress I2C transaction.

I2C: Mixed transfers methods causing Interrupts to hang MCU

STM32CubeIDE v 1.14.0
NUCLEO-L412KB

This issue appears to be the same as
STMicroelectronics/STM32CubeH7#260 (comment)

If I do a DMA transfer over I2C then followed by HAL_I2C_Mem_Write, it hangs. The TXIE is still set after the DMA transfer. If I manually clear it through the IDE before executing the Mem_Write, it does not hang.

HAL_I2C_Mem_Write_IT does not correctly initialize hi2c->XferSize

Describe the bug
If an I2C write transaction fails, the hi2c->XferCount may be left set to a non zero value. Subsequent calls to HAL_I2C_Mem_Write_IT will then ALWAYS fail because the condition hi2c->XferSize == 0U is not met in the interrupt handler

I2C_Master_ISR_IT

  else if ((I2C_CHECK_FLAG(tmpITFlags, I2C_FLAG_TCR) != RESET) && \
           (I2C_CHECK_IT_SOURCE(ITSources, I2C_IT_TCI) != RESET))
  {
    if ((hi2c->XferCount != 0U) && (hi2c->XferSize == 0U))

this causes HAL_I2C_ERROR_SIZE to be returned.

     {
        /* Wrong size Status regarding TCR flag event */
        /* Call the corresponding callback to inform upper layer of End of Transfer */
        I2C_ITError(hi2c, HAL_I2C_ERROR_SIZE);
      
}

A clear and concise description of what the bug is.

How To Reproduce
Perform a failing I2C transaction, then call HAL_I2C_Mem_Write_IT.

Additional context

To fix, unconditionally set hi2c->XferSize =0u in HAL_I2C_Mem_Write_IT.

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

STM32L476RCT6 use freertos and sdio 4bits and dma,can not receive queue

STM32L476RCT6, use CUBEMX generate the project, use FREERTOS ,SDIO 4bits, DMA, and Fatfs, the SD not work normally, the library is STM32Cube_FW_L4_V1.18.0, the question repetition on other library
in fuction
DRESULT SD_read(BYTE lun, BYTE *buff, DWORD sector, UINT count),
event = osMessageGet(SDQueueID, SD_TIMEOUT);

can not receive message.

but use sdio 1bits，work normally.

HAL_UARTEx_ReceiveToIdle_DMA has inconsistent behavior

When using ReceiveToIdle, there seems to be a different behavior for when IDLE and FT happen at the same time. With the HT, we get both interrupts(HT and IDLE), but when FT and IDLE happen to be at sizeof(buf), the code decides the buffer is full and cancels the idle interrupt.

This seems strange when using the DMA in circular buffer mode, there should be no concept of a location being more significant compared to another. I would expect to get both interrupts.

In the case when the incoming data wraps the buffer, we get the FT and IDLE. So now there is no way to just detect IDLE interrupts. If it was consistent and we always received the IDLE interrupt, that would make it easier to discard the HT and FT.

Maybe it could check if the DMA is using CIRCULAR mode and send both interrupts.

To explain our use case, we are receiving packets of variable size. Therefore, the size of the data cannot be used to determine when all the data is received. I am aware there are lots of ways of framing the data to detect the packets, but just being consistent with the IDLE interrupts would make it much easier.

I have read this issue STMicroelectronics/stm32f1xx_hal_driver#4 and read the example code, but it does not solve my issue.

The issue also states:

Use of HAL_UARTEx_ReceiveToIdle_DMA service, will generate calls to
user defined HAL_UARTEx_RxEventCallback callback for each occurrence of
following events :

• DMA RX Half Transfer event (HT)
• DMA RX Transfer Complete event (TC)
• IDLE event on UART Rx line (indicating a pause is UART reception flow)

According to this text, we should get an interrupt for EACH occurrence, but it appears we don't always get the IDLE events.

FLASH_SIZE macro definition is not defined.

Hi，i am a st mcu developer from china , and i have meet some trouble in stm32l4xx_hal_driver lib, lib version is the code on the master branch of this repo.

The FLASH_SIZE macro definition is not defined but it is used in stm32l4xx_hal_flash.h(842 line) file:

#if defined (STM32L471xx) || defined (STM32L475xx) || defined (STM32L476xx) || defined (STM32L485xx) || defined (STM32L486xx) || \
    defined (STM32L496xx) || defined (STM32L4A6xx) || defined (STM32L4P5xx) || defined (STM32L4Q5xx) || defined (STM32L4R5xx) || \
    defined (STM32L4R7xx) || defined (STM32L4R9xx) || defined (STM32L4S5xx) || defined (STM32L4S7xx) || defined (STM32L4S9xx)
#define FLASH_BANK_SIZE                    (FLASH_SIZE >> 1U)
#else
#define FLASH_BANK_SIZE                    (FLASH_SIZE)
#endif

In addition，i have found this defintion code in the v0.3.0(14-Jan-2015) version:

#define FLASH_SIZE_DATA_REGISTER           ((uint32_t)0x1FFF75E0)
    
#define FLASH_SIZE                         ((((*((uint16_t *)FLASH_SIZE_DATA_REGISTER)) == 0xFFFF)) ? (0x400 << 10) : \
                                            (((*((uint16_t *)FLASH_SIZE_DATA_REGISTER)) & (0x0FFF)) << 10))

so, i want to know why these code is removed in the latest version, and how can i solve this problem?

Thanks!

FLASH_SIZE_DATA_REGISTER undeclared

Describe the set-up

• STM32L4A6VG
• ARM GNU GCC 9

Describe the bug

hardware/mcu_hal/stm32l4xx_hal_driver/Inc/stm32l4xx_hal_flash.h:894:102: error: 'FLASH_SIZE_DATA_REGISTER' undeclared (first use in this function)
  894 | #define IS_FLASH_MAIN_MEM_ADDRESS(ADDRESS) (((ADDRESS) >= (FLASH_BASE))         && ((((*((uint16_t *)FLASH_SIZE_DATA_REGISTER)) & (0x0FFFU)) == 0x400U) ? \

How To Reproduce

1. Download stm32l4xx_hal_driver repository
2. Switch to the tag 1.11.0

TX IRQ remains active after HAL_I2C_Mem_Read_DMA

Because HAL_I2C_Mem_Read_DMA MemAddress transmission is based on TX IRQ

stm32l4xx_hal_driver/Src/stm32l4xx_hal_i2c.c

Line 3079 in a4d4011

I2C_Enable_IRQ(hi2c, I2C_XFER_TX_IT);

neither I2C_Mem_ISR_DMA nor I2C_ITMasterCplt will not disable the TX IRQ after the data transfer

stm32l4xx_hal_driver/Src/stm32l4xx_hal_i2c.c

Line 5937 in a4d4011

/* Disable Interrupts and Store Previous state */

Therefore, if a non-IT based transmission such as HAL_I2C_Mem_Write will follow, a TX irq will be triggered without any interrupt callback defined, therefore the IRQ cannot be cleared and results in the program stuck in I2C ISR

One solution is to call I2C_Disable_IRQ(hi2c, I2C_XFER_TX_IT); also for the state HAL_I2C_STATE_BUSY_RX in I2C_ITMasterCplt

FLASH_SIZE define is missing

Describe the set-up

• Using the latest tag in this repo. Along with cmsis_device_l4 v1.7.2.

Describe the bug

• On build I get this:
  error: 'FLASH_SIZE' undeclared

Makefile to Compile the files

Do you have a Makefile to compiled all the files as a single archive/ static library? Thanks

HAL_SPI_TransmitReceive() always returns HAL_BUSY after the first transaction

In HAL_SPI_TransmitReceive() the hspi->State variable remains in HAL_SPI_STATE_BUSY_RX after the first transaction, no further transactions are executed, HAL_BUSY is returned.

It can be solved like this:

1545-
1546-    errorcode = HAL_ERROR;

1553-    errorcode = HAL_ERROR;

1557+    if (hspi->ErrorCode != HAL_SPI_ERROR_NONE)
1558+    {
1559+      errorcode = HAL_ERROR;
1560+    }
1561+      else
1562+    {
1563+      hspi->State = HAL_SPI_STATE_READY;
1564+    }
1565+

HAL_RTCEx_SetTamper_IT Incorrect on STM32L4P5xx and STM32L4Q5xx

The HAL function HAL_RTCEx_SetTamper_IT does not initialise the trigger level properly in TAMP->CR2, the function HAL_RTCEx_SetTamper seems correct though. I suspect the updated code from HAL_RTCEx_SetTamper just needs to be copied across to HAL_RTCEx_SetTamper_IT.

Correct:

stm32l4xx_hal_driver/Src/stm32l4xx_hal_rtc_ex.c

Lines 1767 to 1779 in e494650

	/* Trigger and Filter have exclusive configurations */
	assert_param(((sTamper->Filter != RTC_TAMPERFILTER_DISABLE) && ((sTamper->Trigger == RTC_TAMPERTRIGGER_LOWLEVEL) || (sTamper->Trigger == RTC_TAMPERTRIGGER_HIGHLEVEL)))
	|| ((sTamper->Filter == RTC_TAMPERFILTER_DISABLE) && ((sTamper->Trigger == RTC_TAMPERTRIGGER_RISINGEDGE) || (sTamper->Trigger == RTC_TAMPERTRIGGER_FALLINGEDGE))));
	/* Configuration register 2 */
	tmpreg = tamp->CR2;
	tmpreg &= ~((sTamper->Tamper << TAMP_CR2_TAMP1TRG_Pos) | (sTamper->Tamper << TAMP_CR2_TAMP1MSK_Pos) | (sTamper->Tamper << TAMP_CR2_TAMP1NOERASE_Pos));
	/* Configure the tamper trigger bit */
	if ((sTamper->Trigger == RTC_TAMPERTRIGGER_HIGHLEVEL) || (sTamper->Trigger == RTC_TAMPERTRIGGER_FALLINGEDGE))
	{
	tmpreg |= (sTamper->Tamper << TAMP_CR2_TAMP1TRG_Pos);
	}

Incorrect:

stm32l4xx_hal_driver/Src/stm32l4xx_hal_rtc_ex.c

Lines 1928 to 1936 in e494650

	tmpreg = tamp->CR2;
	/* Clear the bits that are going to be configured and leave the others unchanged */
	tmpreg &= ~((sTamper->Tamper << TAMP_CR2_TAMP1TRG_Pos) | (sTamper->Tamper << TAMP_CR2_TAMP1MSK_Pos) | (sTamper->Tamper << TAMP_CR2_TAMP1NOERASE_Pos));
	if (sTamper->Trigger != RTC_TAMPERTRIGGER_RISINGEDGE)
	{
	tmpreg |= (sTamper->Tamper << TAMP_CR2_TAMP1TRG_Pos);
	}