Skip to content

Fix STM32H7 DMA stream collisions on 5 targets#11706

Open
sensei-hacker wants to merge 1 commit into
iNavFlight:release/9.1from
sensei-hacker:fix/h7-dma-stream-conflicts-5-targets
Open

Fix STM32H7 DMA stream collisions on 5 targets#11706
sensei-hacker wants to merge 1 commit into
iNavFlight:release/9.1from
sensei-hacker:fix/h7-dma-stream-conflicts-5-targets

Conversation

@sensei-hacker

@sensei-hacker sensei-hacker commented Jul 10, 2026

Copy link
Copy Markdown
Member

Summary

Fixes DMA stream (dmaopt) collisions in the timerHardware[] table of 5 STM32H7 targets:
AEDROXH7, KAKUTEH7WING, SEQUREH7, TBS_LUCID_H7_WING, TBS_LUCID_H7_WING_MINI.

On H7's DMAMUX, dmaopt is a flat 0-15 index (0-7 = DMA1 Stream0-7, 8-15 = DMA2 Stream0-7); when two entries share a value, only the first to initialize actually gets DMA — the rest silently lose DShot/WS2812 timing, or on three of these targets, collide with ADC1's hardwired stream (DMA2 Stream0 / dmaopt 8).

I only have the AEDROX for testing myself -- I wasn't able to test the others.

Changes

  • AEDROXH7 — LED strip collided with ADC1. This is a regression from an earlier fix (AEDROXH7: fix LED strip DMA conflict with motor outputs #11629/AEDROXH7: fix LED strip DMA conflict with motor outputs #11630) that copied the wrong dmaopt from sibling boards (used 8 instead of those boards' actual value, 9). Fixed to 9.
  • KAKUTEH7WING — S11, S12, S13, and the LED strip all shared dmaopt 0 with S1. Spread across 9-12.
  • SEQUREH7 — S5, S7, S8, and the LED strip all shared dmaopt 0 with S1. Spread across 4-7. S5 (TIM16_CH1N) had a stale "No DMA" comment — it's actually DMA-capable via the TIM16_CH1 alias in the shared timer_def table, confirmed by tracing the macro chain and independently via gcc -E.
  • TBS_LUCID_H7_WING — LED strip collided with ADC1; S9 and S11 also shared dmaopt 0 with S1. Moved LED to 10, S9/S11 to 11/12.
  • TBS_LUCID_H7_WING_MINI — LED strip collided with ADC1. Fixed to 9.

Testing

I only have the AEDROX board to actually test on hardware

  • Re-ran check_dma_conflicts.py --target <NAME> on each target after the fix — zero CERTAIN findings remain on all 5.
  • Every reassignment cross-checked against timer_def_stm32h7xx.h (DMAMUX capability per channel), adc_stm32h7xx.c (ADC1/2/3 hardwired streams), and each target's own ADC_INSTANCE/existing table entries to confirm the new value is genuinely free
  • All 5 targets build clean: no warnings, no flash/RAM overflow.
  • Build-test only for four of the boards

Each target's timerHardware table assigned two or more entries to the
same dmaopt (DMA stream) value, so only the first entry initialized
would actually get DMA; the others silently lost DShot/WS2812 timing
or, on three of the targets, collided with ADC1's hardwired stream.

- AEDROXH7: LED strip collided with ADC1 (DMA2 Stream0); this was a
  regression from an earlier fix that copied the wrong dmaopt from
  sibling boards. Moved to dmaopt 9, matching those boards' actual
  value.
- KAKUTEH7WING: four outputs (S11-S13, LED) shared dmaopt 0 with S1.
  Spread across dmaopt 9-12.
- SEQUREH7: four outputs (S5, S7, S8, LED) shared dmaopt 0 with S1.
  Spread across dmaopt 4-7. S5 (TIM16_CH1N) was mislabeled "No DMA"
  in a comment; it is DMA-capable via the TIM16_CH1 alias table.
- TBS_LUCID_H7_WING: LED strip collided with ADC1; two more outputs
  (S9, S11) shared dmaopt 0 with S1. Moved LED to dmaopt 10, S9/S11
  to 11/12.
- TBS_LUCID_H7_WING_MINI: LED strip collided with ADC1. Moved to
  dmaopt 9.

Verified with check_dma_conflicts.py and confirmed against the H7
DMAMUX/ADC driver source per target; all 5 build clean.
@sensei-hacker sensei-hacker added this to the 9.1 milestone Jul 10, 2026
@qodo-code-review

Copy link
Copy Markdown
Contributor

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

@github-actions

Copy link
Copy Markdown

Test firmware build ready — commit 1044189

Download firmware for PR #11706

243 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant