Fix STM32H7 DMA stream collisions on 5 targets#11706
Open
sensei-hacker wants to merge 1 commit into
Open
Conversation
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.
Contributor
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
Test firmware build ready — commit Download firmware for PR #11706 243 targets built. Find your board's
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes DMA stream (
dmaopt) collisions in thetimerHardware[]table of 5 STM32H7 targets:AEDROXH7, KAKUTEH7WING, SEQUREH7, TBS_LUCID_H7_WING, TBS_LUCID_H7_WING_MINI.
On H7's DMAMUX,
dmaoptis 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
dmaoptfrom sibling boards (used 8 instead of those boards' actual value, 9). Fixed to 9.dmaopt0 with S1. Spread across 9-12.dmaopt0 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 viagcc -E.dmaopt0 with S1. Moved LED to 10, S9/S11 to 11/12.Testing
I only have the AEDROX board to actually test on hardware
check_dma_conflicts.py --target <NAME>on each target after the fix — zero CERTAIN findings remain on all 5.timer_def_stm32h7xx.h(DMAMUX capability per channel),adc_stm32h7xx.c(ADC1/2/3 hardwired streams), and each target's ownADC_INSTANCE/existing table entries to confirm the new value is genuinely free