`dma_stm32: Transfer Error` when using OSPI flash with DMA

[kamnxt]

Describe the bug

I'm using DMA with OSPI on a STM32U5A5, and keep getting transfer errors. The log output seems to suggest that the callback is somehow called before the transfer complete flag is set.

The same setup works fine without DMA configured, and happens less frequently at lower frequencies.

Regression

• This is a regression.

Steps to reproduce

Build with the dmas and dma-names properties commented out, things work fine.
Build with them uncommented, and the log is spammed with transfer errors.
Lower the ospi-max-frequency (for example all the way down to 5M) and the errors only occur sporadically.

Relevant log output

[00:00:08.350,000] <err> dma_stm32: Transfer Error.
[00:00:08.350,000] <inf> dma_stm32: tc: 0, ht: 0, dte: 0, ule: 0, use: 0
[00:00:08.350,000] <err> flash_stm32_ospi: DMA callback error with channel 12.
[00:00:08.374,000] <err> dma_stm32: Transfer Error.
[00:00:08.374,000] <inf> dma_stm32: tc: 0, ht: 0, dte: 0, ule: 0, use: 0
[00:00:08.374,000] <err> flash_stm32_ospi: DMA callback error with channel 12.

Impact

Functional Limitation – Some features not working as expected, but system usable.

Environment

No response

Additional Context

Using the following DTS:

&octospi1 {
    pinctrl-0 = <&octospim_p1_clk_pf10 &octospim_p1_ncs_pa2
                 &octospim_p1_io0_pf8 &octospim_p1_io1_pf9
                 &octospim_p1_io2_pf7 &octospim_p1_io3_pf6>;
    pinctrl-names = "default";

    dmas = <&gpdma1 12 40 0>; /* OCTOSPI request ID = 40, flags not used */
    dma-names = "tx_rx";

    status = "okay";

    mx25l25645g: ospi-nor-flash@0 {
        compatible = "st,stm32-ospi-nor";
        reg = <0 DT_SIZE_M(32)>;
        ospi-max-frequency = <DT_FREQ_M(50)>;
        /* WP# and RESET# pin used for data lines in QUAD mode,
         * reset-gpios cannot be used in combination.
         */
        spi-bus-width = <OSPI_QUAD_MODE>;
        status = "okay";
        /* Supports DTR (double transfer rate)
         * Flash driver only allows DTR with OPI mode (8 line mode).
         */
        data-rate = <OSPI_STR_TRANSFER>;
        four-byte-opcodes;
    };
};

A coworker suggested he has seen a similar issue on another STM32, where the ISR somehow got called before the flags were set. Adding a small patch to poll the flags a few times before giving up seems to cause the problem to go away:

diff --git a/drivers/dma/dma_stm32u5.c b/drivers/dma/dma_stm32u5.c
index 88ab979df62..76445ac59a7 100644
--- a/drivers/dma/dma_stm32u5.c
+++ b/drivers/dma/dma_stm32u5.c
@@ -265,6 +265,12 @@ static void dma_stm32_irq_handler(const struct device *dev, uint32_t id)
       }
       callback_arg = id + STM32_DMA_STREAM_OFFSET;
       stream->busy = false;
+      for(int i = 0; i < 100; i++) {
+              if (!(stm32_dma_is_tc_irq_active(dma, id) | stm32_dma_is_ht_irq_active(dma, id))) {
+                      // check the flags a few times, because sometimes the interrupt comes early
+                      // for some reason
+              }
+      }
 
       /* The dma stream id is in range from STM32_DMA_STREAM_OFFSET..<dma-requests> */
       if (stm32_dma_is_ht_irq_active(dma, id)) {

[github-actions]

Hi @kamnxt! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[mkaranki]

Hi,

Some info to hopefully help in here. I have seen these errors as well. stm32 HAL is enabling OCTOSPI DMA half transfer interrupt unconditionally, which I believe affects this. The driver is not really utilizing the half transfer interrupt, so I have disabled it. Then I have not seen these errors anymore.

The patch to the STM HAL I have used is attached. It for sure bit ugly one but does the job. Would be nice to think is this really the root cause, and in any case get a permanent fix to the upstream to the issue whatever it is.

Could it be that dma_stm32_irq_handler clears both ht and tc flags on ht interrupt call and thus it seems like the 2nd interrupt handler call invoked due to tc is called without reason? Or maybe there's interrupt nesting happening?

0000-disable-ospi-dma-ht-interrupt.patch

[FRASTM]

I understand the irq HT is disturbing the transfer, in that case could the IRQ simply not be enabled in the dma_stm32_configure() ?
Do you mean ?
// LL_DMA_EnableIT_HT(dma, dma_stm32_id_to_stream(id));

Then the dma irq should not be triggered with HT flag

[mkaranki]

I understand the irq HT is disturbing the transfer, in that case could the IRQ simply not be enabled in the dma_stm32_configure() ? Do you mean ? // LL_DMA_EnableIT_HT(dma, dma_stm32_id_to_stream(id));

Then the dma irq should not be triggered with HT flag

stm32 ospi flash driver, or more precisely function flash_stm32_ospi_init, is configuring DMA via STM32 HAL, and calling zephyr's dma_config with flag:

         /* HACK: This field is used to inform driver that it is overridden */
        dma_cfg.linked_channel = STM32_DMA_HAL_OVERRIDE;

So the DMA configuration is largely skipped. That LL_DMA_EnableIT_HT is never called in that case (and it's only for cyclic DMA anyways in the driver).

The DMA is configured via STM32 HAL by flash_stm32_ospi_init and with it I recall there's no way to disable half-transfer interrupt (w/o modifying the HAL itself) when using the high level OSPI API (HAL_OSPI_Transmit_DMA and HAL_OSPI_Receive_DMA) like the flash driver is doing.

[FRASTM]

I understand the irq HT is disturbing the transfer, in that case could the IRQ simply not be enabled in the dma_stm32_configure() ? Do you mean ? // LL_DMA_EnableIT_HT(dma, dma_stm32_id_to_stream(id));
Then the dma irq should not be triggered with HT flag

stm32 ospi flash driver, or more precisely function flash_stm32_ospi_init, is configuring DMA via STM32 HAL, and calling zephyr's dma_config with flag:

         /* HACK: This field is used to inform driver that it is overridden */
        dma_cfg.linked_channel = STM32_DMA_HAL_OVERRIDE;

So the DMA configuration is largely skipped. That LL_DMA_EnableIT_HT is never called in that case (and it's only for cyclic DMA anyways in the driver).

The DMA is configured via STM32 HAL by flash_stm32_ospi_init and with it I recall there's no way to disable half-transfer interrupt (w/o modifying the HAL itself) when using the high level OSPI API (HAL_OSPI_Transmit_DMA and HAL_OSPI_Receive_DMA) like the flash driver is doing.

Correct.
In order to avoid changing the hal module, I see from your ananlysis that the dma_stm32_irq_handler should ignore the stm32_dma_is_ht_irq_active()

Could this be done with a special configuration of the dma channel, when OSPI is transferring through GPDMA : if we had the dma_cfg.linked_channel set to a new value, something like "STM32_DMA_HAL_OVERRIDE | STM32_DMA_HAL_NO_HT_IT"
then dma_stm32_irq_handler skips the stm32_dma_is_ht_irq_active part if dma_cfg.linked_channel has STM32_DMA_HAL_NO_HT_IT.