Caution

This issue is not on your file but on the compiler.
However it has impact on your customers and it's in your interest to make ARM/GCC fix the issue. This issue can at least serve as notice of heads-up for next people that will encounter the problem.

Describe the set-up

• arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi.zip from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads will segfault on compilation of stm32u5xx_hal_dma_ex.c with -O3

Describe the bug (skip if none)

Compiler segfault

How to reproduce the bug (skip if none)

1. Downloaded arm-gnu-toolchain-12.2.rel1-mingw-w64-i686-arm-none-eabi.zip from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads
2. In attached zip, modify and run compilerBug.bat (will just compile 1 faulty file known to work)
3. observe segmentation fault in compiler

minimalInc.zip

Additional context

I have already reported bug on Linaro: https://bugs.linaro.org/show_bug.cgi?id=5924

Screenshots

C:\FW>"C:\GIT\FW_Toolchain\GNU Tools ARM Embedded\12.2.rel1\bin\arm-none-eabi-gcc.exe" -DSTM32U575xx=1 -IC:/FW/minimalInc -O3 -DNDEBUG -freport-bug -mcpu=cortex-m33 -mthumb -mfpu=fpv5-sp-d16 -mfloat-abi=hard --specs=nano.specs -ffunction-sections -fdata-sections -fno-builtin -Wall -Wfatal-errors -O3 -std=gnu17 -o stm32u5xx_hal_dma_ex.c.obj -c C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c
during GIMPLE pass: evrp
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c: In function 'HAL_DMAEx_List_ReplaceNode_Head':
C:/FW/minimalInc/stm32u5xx_hal_dma_ex.c:4689:1: internal compiler error: Segmentation fault
 4689 | }
      | ^
Please submit a full bug report, with preprocessed source.
See <https://bugs.linaro.org/> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.

Describe the set-up

• custom board
• OZone

Describe the bug (skip if none)

I am interfacing a SPI graphics controller on STM32U585 and to update the frame buffer data, I have to send a single byte of command followed by n bytes as RGB data(more than 65532 bytes), however between I have to toggle a GPIO in between, which controls command/data mode.

To accomplish this, I am sending the single command byte by using HAL_SPI_Transmit_IT, and eventually I will toggle the GPIO and initiate the TX DMA transmission for RGB data on HAL_SPI_TxCpltCallback and by using HAL_SPI_Transmit_DMA(multiple iterations as the whole data is more than 65532 bytes which exceed the single shot of DMA).

Crash happens in the following line as hspi->hdmarx is null in time of comparison due to not using RX DMA.

if (HAL_IS_BIT_CLR(cfg1, SPI_CFG1_TXDMAEN | SPI_CFG1_RXDMAEN) ||
((hspi->hdmarx) && (State != HAL_SPI_STATE_BUSY_RX) && (hspi->hdmarx->Mode != DMA_LINKEDLIST_CIRCULAR)) ||
((hspi->hdmatx) && (State != HAL_SPI_STATE_BUSY_TX) && (hspi->hdmatx->Mode != DMA_LINKEDLIST_CIRCULAR)))

Additional context
I have changed that comparison line as follow:

/* DMA Normal Mode */ if (HAL_IS_BIT_CLR(cfg1, SPI_CFG1_TXDMAEN | SPI_CFG1_RXDMAEN) || ((hspi->hdmarx) && (State != HAL_SPI_STATE_BUSY_RX) && (hspi->hdmarx->Mode != DMA_LINKEDLIST_CIRCULAR)) || ((hspi->hdmatx) && (State != HAL_SPI_STATE_BUSY_TX) && (hspi->hdmatx->Mode != DMA_LINKEDLIST_CIRCULAR)))

but another issue I am facing now is that actually my DMA transmission will only work once and would fail in the second iteration as SPI state is not equal to HAL_SPI_STATE_READY in time of calling HAL_SPI_Transmit_DMA in HAL_SPI_TxCpltCallback. It seems that SPI state would not be resetted in the second call of HAL_SPI_TxCpltCallback which would happen the after completion of first DMA transmission.

Apparently, the following line of code would not get called at all to close the transfer:
SPI_CloseTransfer

Actually after completion of first DMA transfer, SPI_CFG1_TXDMAEN is 1 so the comparison would fail and the aforementioned line would not get called.

I wonder if this is an edge case flaw? Or if I am not able to perform the next DMA transfer in HAL_SPI_TxCpltCallback at all?

RCC_CCIPR1_ICLKSEL_0 and RCC_CCIPR1_ICLKSEL_1 are not not defined, so stm32u5xx_hal_rcc_ex.c faces compile errors due to missing of these definitions (and forwarded ones, like RCC_ICLK_CLKSOURCE_PLL2)

#if defined (__ARM_FEATURE_CMSE) && (__ARM_FEATURE_CMSE == 3U) is false
assert is empty

Also stm32u5xx_hal_rcc.c line 1552, 2007, 2064.

Env: STM32Cube IDE 1.8.0
U5 MCU package ver 1.0.2

In trying to get Zephyr RTOS working on the Nucleo U545RE-Q board, I discovered header inclusion issues building the HAL for the STM32U545 SoC.

Zephyr RTOS makes use of the "stm32u5xx_hal_driver" for some interactions with the ST hardware, and builds the HAL by copying the default "stm32_hal_conf_template.h" to "stm32_hal_conf.h", leaving all options enabled.

However, some of the modules (specifically HAL_SRAM_MODULE_ENABLED, HAL_NAND_MODULE_ENABLED and HAL_NOR_MODULE_ENABLED) do not compile for the STM32U545. Based on recommendations from a engineer in the Zephyr forums, I modeled changes to four files ((stm32u5xx_hal_sram.h, stm32u5xx_hal_nor.h, stm32u5xx_hal_nand.h and stm32u5xx_ll_fmc.h) with appropriate "#ifdef" checks using the example for the "stm32g4xx_hal_driver", and this allows the code to build for the U545 series. Clearly, I'd appreciate ST (and others) review of these changes to ensure correctness.

I'll submit a PR shortly so the changes can be reviewed.

Release is 1.1.0

I only tried to compile stm32u5xx_hal_ospi.h and I get a compiler error. In fact OCTOSPI_CR_DQM is defined nowhere
There has been renamming between OCTOSPI_CR_DMM and OCTOSPI_CR_DQM ?

also RCC_CCIPR1_CLK48MSEL_0 is defined nowhere
same for RCC_CCIPR1_CLK48MSEL

How could this release even pass any automated test tool ?