Change DMA2 to DMA1 for FSMC TFT on STM32F1xx

[konradmb]

Description

This PR fixes the #26970 bug where it's impossible to start a print from SD card using COLOR_UI interface. I've changed TFT DMA channel from 2 to 1.
Basically it reverts the part that initializes DMA to the behaviour before commit 9364cbb.

I've guessed that there's something involving differences in STM32 and GD32 features that manifests in #26970 and that was it.
I don't know the details of this change and how this will impact other features, but it fixed this bug in my printer.

Prior art:

• Miscellaneous TFT improvements #25359
• [BUG]Print task is not started on Marlin 2.1.2 from MKS TFT35 #25157 (comment)
• jmz52@1940418#diff-f64f057c8653ee97ebf3be2065e2d0e14ec568be6ab1e03c98b5282fbf1e4ecf
• [BUG] M23/M24 over serial works but starting print from TFT doesn't #25393 (comment)

Requirements

• KP3S (or maybe other boards) with GD32F103VE

Benefits

Fixes #26970

Configurations

Attached in #26970

Related Issues

#26970 #26927

[konradmb]

@piegolf can you test this?

[AR1972]

applied the patch, built and installed, started a print, bed is warming. Working for me.

[piegolf]

tested it on my kp3s, it fixed the issue (#26970) and the print completed successfully

[konradmb]

Pinging @jmz52 (#26747 changed your DMA's from #25359).

[konradmb]

I've just found out that adding TFT_SHARED_IO from Marlin/src/HAL/STM32F1/tft/tft_fsmc.cpp (libmaple) and enabling it in config, while leaving DMA2 also fixes this issue.

diff --git a/Marlin/src/HAL/STM32/tft/tft_fsmc.cpp b/Marlin/src/HAL/STM32/tft/tft_fsmc.cpp
index 4dffe8b4fc..21f47848e3 100644
--- a/Marlin/src/HAL/STM32/tft/tft_fsmc.cpp
+++ b/Marlin/src/HAL/STM32/tft/tft_fsmc.cpp
@@ -182,6 +186,8 @@ void TFT_FSMC::transmitDMA(uint32_t memoryIncrease, uint16_t *data, uint16_t cou
   DMAtx.Init.PeriphInc = memoryIncrease;
   HAL_DMA_Init(&DMAtx);
   HAL_DMA_Start(&DMAtx, (uint32_t)data, (uint32_t)&(LCD->RAM), count);
+  
+  TERN_(TFT_SHARED_IO, while (isBusy()));
 }
 
 void TFT_FSMC

[thinkyhead]

I've just found out that adding TFT_SHARED_IO from Marlin/src/HAL/STM32F1/tft/tft_fsmc.cpp (libmaple) and enabling it in config, while leaving DMA2 also fixes this issue.

Should the extra wait loop for TFT_SHARED_IO be added regardless of whether it's DMA1 or 2, or should it only apply to 2?

[thinkyhead]

From my conversations with a prestigious LLM it appears that SDIO often uses DMA2_Channel4 and that is indeed what we specifically use for SDIO in Marlin on STM32F1. Since we know this to be the case, choosing DMA1 to avoid the conflict altogether seems to be a good choice. Marlin also does this…

hdma_sdio.Init.Priority = DMA_PRIORITY_LOW;

…and…

(FSMC).Init.Priority = DMA_PRIORITY_HIGH;

If SDIO is given DMA_PRIORITY_HIGH that might also solve the issue.

[konradmb]

@thinkyhead From the bug logic description it would be more economic to wait only when DMA2 is active, as it worked good and nobody complained until we've started to use DMA2.

One case against is the description provided in Configuration.h. I understand that as it would disable async unconditionally, irregardless of other states.

#define TFT_SHARED_IO   // I/O is shared between TFT display and other devices. Disable async data transfer.

The other case against is that in the long run it would be wiser to leave it only behind TFT_SHARED_IO define to prevent this bug from resurfacing again.

I would apply it to both DMA1 and DMA2 if TFT_SHARED_IO is enabled, but I think I'm not experienced enough to provide a good advice. Also I don't understand how the GD32 hardware bug happens in detail and why.

[thinkyhead]

The TFT_SHARED_IO setting puts it in the hands of users / vendors to decide whether there's some contention going on between DMA channels, but it seems like we could figure this out from our implementations and set this in the pins files (or future LCD pins files) when the DMA channel for SPI / FSMC has contention with something else, such as SDIO.

Anyway, it does seem like a good idea, even in the shared I/O situation, to make the SDIO priority a bit higher than the FSMC priority. It seems like LOW is the wrong priority anyway.

I can't test these things here, but I would very much like to know how the machine behaves when SDIO priority is set to MEDIUM and HIGH while FSMC is still set to HIGH, and then I'd like to see how it behaves when the FSMC priority is set to MEDIUM or LOW, also with SDIO set to LOW/MEDIUM/HIGH. So basically, I'd like to see a matrix… both with and without TFT_SHARED_IO (wait loop) enabled.

In the end we'll probably just set the FSMC to use DMA1 instead of DMA2 so it doesn't interact at all with SDIO, but while they are still using the same DMA it would be very useful to know whether SDIO remains unreliable under all combinations of priority compared to FSMC or if it can work happily alongside it as long as the priorities are sensible.

[thinkyhead]

@rhapsodyv — Is there any reason you can think of that we should not do this?

[rhapsodyv]

Changing defaults are always prone to break someone’s setup…
And if you take a look in the history, you will see that it’s no the first time this same line change between dma channels.

In this case, I think the best would add to the board pin file the right dma to use, or at least allow it be overwritten by the env build flags… so Marlin doesn’t need to back and forth changing dma channels in the code each time it doesn’t work for someone.

[thinkyhead]

Thanks for your comments!

Changing defaults are always prone to break someone’s setup…

It's definitely possible that this could break something for someone, so this change is definitely a tenuous one that we want to keep an eye on. Most advice I found in searches pointed to using a slightly higher priority for SDIO or a slightly lower priority for FSMC. If we haven't gotten any definitive feedback about this change before 2.1.3-beta1 is ready, I'll mark it as an important bullet point for testers.

For testing purposes it would be best to get feedback from those who were definitely affected by the DMA contention issue, but I do have a small pile of STM32-based boards, a few with FSMC, and some are inside printers. If I have one of the specifically affected boards or printers I can also try to make SDIO break and see what happens when priorities are adjusted.

best would add to the board pin file the right dma to use

Some boards do specify FSMC_DMA_DEV and FSMC_DMA_CHANNEL. (For example Mingda D2 has DMA1 and DMA_CH4) but these only seem to apply to our deprecated Maple environments. For others the DMA is based on the HAL, but that follows from the ports and interrupts specified by the boards/variants.

So, I'll have to do a board-by-board audit to see which DMA they use. I should also make a big Google spreadsheet with all our board information laid out for easy reference. (I'll ask an LLM to help with that.) Most boards are based on a generic STM32 layout but we can look at each one and make sure that the DMA we've picked is correct, and if there is a need to add overrides on a per-board basis we'll also add that capability. I hope we can automatically figure out most of these things on the users' behalf from things like pins and header defines so they don't have to think about it.

[thinkyhead]

We'll gather our board / environment info in this here spreadsheet…. A single board may have more than one environment with different DMA settings, and that's what we'll discover from populating this sheet.

https://docs.google.com/spreadsheets/d/10Wsch_IduVArjNApnnBtpQlc1-TRjwyaRo6-FanhCYI/edit?usp=sharing